>> “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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
