3 of the most well-known new languages in the past decade (Swift, Rust, and Go, respectively) have all eschewed exceptions for control flow in favor of some sigil in the source code to propagate errors explicitly. Swift uses try-statements (along with a few other control flow constructs), Rust uses the "?" operator (previously the try! macro), and Go uses "if err != nil".
C++, a language which does have exceptions, has significant fractions of its user base which disable exception support entirely (20% according to a survey) or partially (52%). Google, for instance, almost invariably compiles with -fno-exceptions and uses macros to propagate errors explicitly (see https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/stubs/status_macros.h#L49 to get a sense for how that works). Herb Sutter, one of the well-known members of the C++ standards committee from Microsoft, has proposals out to make propagating exceptions require a visible sigil in the source code (also a "try" expression, FWIW): https://youtu.be/os7cqJ5qlzo?t=2939 (an interesting talk overall, I've linked to the specific relevant time). His actual proposal paper is also an interesting read: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0709r3.pdf. In a table with the following introduction "This section lays out what I believe are ideal error handling characteristics. They are not unique to C++; I believe they apply to most modern languages", he lists "Unhandled error propagation is visible" as something not provided by C++ exceptions today. It's possible that a decade from now, this will all have been a minor blip, and you will eventually be proven right. But at the very least, this context that should inform your priors. Sanjay PS - checked exceptions don't really have a great leg to stand on either (e.g. consider their interaction with Java 8's streams: https://www.oreilly.com/ideas/handling-checked-exceptions-in-java-streams, or consider that both Scala and Kotlin don't implement support for them at all) On Sunday, June 30, 2019 at 7:34:54 PM UTC-7, robert engels wrote: > > I’ve developed systems that wrap checked exceptions in unchecked ones, but > in every case I can think of it was to “abort to the top” - returning > control (or exiting) - it is a specialized case of the re-throw, but I > would argue it is rarely used in anything other than framework type code, > with applications code typically wrapping the specific exception in an > “higher-level application checked exception”, that the upper layers handle > (possibly inspecting the “cause” exception. > > As to not answering the question about transferring across Go routines, I > apologize. It was not intentional - I read the statement a few times and > didn’t quite get the concern - and meant to get back to it and forgot - but > I read it again a few times and still don’t understand the problem. > > What is particular about Go that makes this difficult? It is pretty common > practice to pass exceptions across threads in Java and C++ - e.g. fork/join > and the worker thread throws an exception - the exception is passed to the > joining thread. Conceptually, it is as if the function was called serially > and the exception thrown at the fork point. In these cases the exception is > wrapped, but it has to be because of the strong type system. It is also > pretty trivial to declare a wrapper function that declares the checked > exceptions for clarity - this is done routinely in rpc using proxies. > > > On Jun 30, 2019, at 8:43 PM, Ian Lance Taylor <ia...@golang.org > <javascript:>> wrote: > > > > On Sun, Jun 30, 2019 at 5:23 PM robert engels <ren...@ix.netcom.com > <javascript:>> wrote: > >> > >> I am going to disagree here. I don’t think ‘checked exceptions’ exhibit > this behavior. Addressing the points from the Joeal article, > > > > Checked exceptions address some of the difficulties with exceptions. > > However, they introduce new difficulties, and I do not believe they > > work in large-scale programs. In practice, checked exceptions > > degenerate into unchecked exceptions. Changing the set of exceptions > > that a function throws forces all callers to adjust their set of > > exceptions. In practice this is so painful that programs catch > > exceptions and turn into them into unchecked exceptions. There are a > > number of discussions on the Interwebs about the problems with checked > > exceptions; here's one: https://www.artima.com/intv/handcuffs.html . > > > > I note that you didn't reply to my comment about passing errors across > > goroutines. > > > > Ian > > > > -- > > You received this message because you are subscribed to the Google > Groups "golang-nuts" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to golan...@googlegroups.com <javascript:>. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWZEg091q2Z2bmNrbgewOPH-TMGnoc1hB4V44tMtGyzuw%40mail.gmail.com. > > > > For more options, visit https://groups.google.com/d/optout. > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/3ac00e65-7476-40b5-8328-3aef547e0541%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
