I agree that exceptions are definitely not in vogue, but there are a lot of things that are which I also don’t agree with - e.g. using Python to write anything more than page long scripts, writing major applications in JS, etc.
As someone that lived through the C errno days, and has spent a considerable portion of his career being brought in to fix things, I will firmly state that understanding and debugging a large system is far easier when exceptions are used correctly. Maybe a happier - at least for me :) - middle ground for Go would be to treat errors as a specialized type internally, and then to provide stack trace and chain information automatically (when using try) - carrying this information in a side channel that could be inspected/logged when required. I realize that this is completely anecdotal and most likely incorrect and really doesn’t prove anything :) - but I did a cursory review of major projects in Go and Java yesterday, and the defect rates on the Go side (reported issues filtered by bugs) seems far greater for similar code base sizes. I have a feeling this Go error handling has a small part in this - errors are harder to track down. > 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/6B623EF8-6CF0-4895-ACA2-0B136E2B2292%40ix.netcom.com. For more options, visit https://groups.google.com/d/optout.
