Also, I already pointed out the problems of exceptions in functional designs (e.g. streams), luckily and thankfully for us Go doesn’t have that concern :)
> On Jul 1, 2019, at 1:46 AM, Sanjay <balasan...@gmail.com> wrote: > > 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> wrote: >> > >> > On Sun, Jun 30, 2019 at 5:23 PM robert engels <ren...@ix.netcom.com> >> > 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. >> > 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. -- 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/FF9885D2-999D-428E-8FFC-874AB3CD7A05%40ix.netcom.com. For more options, visit https://groups.google.com/d/optout.
