[swift-evolution] ABI of throwing

Tue Aug 9 15:40:45 CDT 2016

>> “Zero cost” EH is also *extremely* expensive in the case where an error is actually throw in normal use cases.  This makes it completely inappropriate for use in APIs where errors are expected in edge cases (e.g. file not found errors).
> 
> Anecdote: I work with a web service that gets several million hits a day. Management loves to use the percentage of succeeding web requests as a measure of overall health. The problem with that metric is that when a web request fails, clients fall in an unhealthy state and stop issuing requests for a while. Therefore, one failing request prevents maybe twenty more that would all have failed if the client hadn't bailed out, but these don't show in statistics. This makes us look much better than we actually are.
> 
> If I had any amount of experience with DTrace, I'd write a script that logs syscall errors to try and see how the programs that I use react to failures. I'm almost certain that when one thing stops working, most programs backs out of a much bigger process and don't retry right away. When a program fails to open a file, it's also failing to read/write to it, or whatever else people normally do after they open files. These things are also expensive, and they're rarely the type of things that you need to (or even just can) retry in a tight loop. My perception is that the immediate cost of failing, even with expensive throwing, is generally dwarfed by the immediate cost of succeeding, so we're not necessarily losing out on much.
> 
> And if that isn't the case, there are alternatives to throwing that people are already embracing, to the point where error handling practices seem fractured.
> 
>>> I don't really know what to expect in terms of discussion, especially since it may boil down to "we're experts in this fields and you're just peasants”
>> 
>> I’m not sure why you think the Swift team would say something that derogatory.  I hope there is no specific action that has led to this belief. If there is, then please let me know.
> 
> Of course not. All of you have been very nice and patient with us peasants, at least as far as "us" includes me. :)

Sorry for derailing the actual error handling discussion. I just wanted to say this:

Don't think less of yourself or devalue your experience and opinions because you don't write a compiler or a programming language for a living. I don't do either of those two things either. 

A diverse set of perspectives and experiences will only benefit the design of the language and its libraries. 

As an example, later when it's time to discuss concurrency, different contexts and perspectives will have different priorities. For some it will be about responsive UIs, for others it will be parallelism, fault tolerance, distributed programming, and more.

If your perspective isn't represented in those discussions then that could mean that valuable information isn't taken into the appropriate consideration. 

Even if certain topics can get heated at times, someone's _idea_ or point of view can be discussed, reasoned about, and be turned down without it in anyway being intended towards that person. 

So just like me, try not to get discouraged by all the other smart people on this mailing list that have other experience and know so much about other things than you and I do. :)

That said, back to the discussion about error handling ;)

> This was meant as a light-hearted reflection on discussing intimate parts of the language, where my best perspective is probably well-understood desktop/server development, whereas the core team has to see that but also needs a high focus on other things that don't even cross my mind (or at least, that's the heroic picture I have of you guys).
> 
> For instance, my "expensive" stops at "takes a while". Your "expensive" might mean "takes a while and drains the very finite energy reserves that we have on this tiny device" or something still more expansive. These differences are not always immediately obvious.
> 
>>> However, as linked above, someone did for Microsoft platforms (for Microsoft-platform-style errors) and found that there is an impact. 
>> 
>> C++ and Swift are completely different languages in this respect, so the analysis doesn’t translate over.
> 
> The analysis was (probably?) done over C++ and HRESULTs but with the intention of applying it to another language (Midori), and it most likely validated the approach of other languages (essentially everything .NET-based). Several findings of the Midori team are being exported to Microsoft's new APIs, notably the async everywhere and exceptions everywhere paradigms, and these APIs are callable from both so-called managed programs (GCed) and unmanaged programs (ref-counted).
> 
> Swift operations don't tend to throw very much, which is a net positive, but it seems to me that comparing the impact of Swift throws with another language's throws is relatively fair. C# isn't shy of FileNotFoundExceptions, for instance.
> 
>> Yes, and many C++ projects build with -fno-exceptions because of the huge code and metadata bloat associated with them.  This is one of many mistakes in C++/Java/etc that we do not want to repeat with Swift.  Additionally, unlike Java, Swift doesn’t generally have the benefit of a JIT compiler that can lazily create these structures on demand.
> 
> Yes. I believe that you are familiar with a couple of such C++ projects. :)
> 
> As we've seemingly agreed, Swift only needs metadata and code for functions that call functions that throw. Also, I understand that we don't need EH tables with the current approach, but my understanding is that the cleanup code needs to exist regardless of how control is transferred to it. (I have no notion of how big EH table entries have to be, so I won't attempt any comparison with the size of the equivalent dispatch code. I'm pretty sure that it's unfavorable.)
> 
> All in all, I guess that this is an area of Swift that goes against trends that are overall satisfying in my domain. Of course, I'm writing all of this because I like Swift and I want an ABI that will make it the best choice (or close) for the things that I want to do with it. I'm a little concerned that what's best for a watch isn't necessarily what's best for a server and that what's best for a compiler back-end isn't necessarily what's best for a UI program, but Swift tries position itself for all of these.
> 
> Félix
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160809/77402bd3/attachment.html>