I've had this argument before, regarding both Go and Rust. The history goes like this:<p>1. Exceptions suck! Look at the mess in Java and C++. In our new language we're not going to have exceptions. We get rid of all that complicated "unwinding" stuff, too.<p>2. Look at all that error handling code in our new language! 2/3 of the lines are about errors. For the really bad ones, we'll have "panic", and you can't recover from a panic.<p>3. We need to recover from panics in production! So we'll add a catch or recover mechanism.<p>4. When we recover, everything is messed up and we get memory leaks and stuff that's not closed! We need proper unwinding so files and connections get closed.<p>5. OK, now we have all the machinery for exceptions, but don't use them! Exceptions are bad! Except where cool people use them. Besides, their syntax sucks and it's hard to send useful info with a panic.<p>6. Oh, hell, put real exception support in the language.<p>Go and Rust went through each of those steps and are now at step 5.
IMO Go's error handling is a flop. I constantly see code with the same verbose error checking that simply shoves the error further up the stack. No better than try/catch. Maybe and Either are much more elegant solutions that allow errors to be checked when values are needed rather than when they are created. I also really like monadic catch/throw.<p>Panic is an anti-pattern, I think, and seems oddly placed as I think the article was illustrating. Once again, these types of failures would be easier to represent with a richer type system.
This post reminds me of a scene from That 70's Show where the wife walks up to the husband and asks "do you think I am smart?" and replies "oh, we're gonna fight today"<p><a href="https://i.imgur.com/3l3NMrv.jpg" rel="nofollow">https://i.imgur.com/3l3NMrv.jpg</a>
Go seems like a bad venue to compare the value- and jump- based approaches to error handling, because its value-based error handling is so poor that it ends up pushing people towards jump-based handling. I'd be more interested in reading about this in Haskell or Rust or whatever.<p>I also don't think anyone should be allowed to write, or read, about error handling unless they've read and digested 'The Error Model':<p><a href="https://news.ycombinator.com/item?id=11054912" rel="nofollow">https://news.ycombinator.com/item?id=11054912</a><p>And if they have, they should be required to say so at the start of their article, so i know i'm not wasting my time reading it! :)<p>I would say that one of the lessons from the evolutions of errors in Rust is a sort of negative-space analogue of Animats' story - that with sufficient syntactic sugar, value-based error handling behaves pretty much the same as jump-based error handling, and that we shouldn't think of them as alternatives, but as directions on a continuum. A bit like how we realised that garbage collection and reference counting are on a continuum:<p><a href="https://news.ycombinator.com/item?id=14823054" rel="nofollow">https://news.ycombinator.com/item?id=14823054</a><p>The most interesting thing i've read on this recently is the proposal for "Herbceptions" in C++:<p><a href="https://news.ycombinator.com/item?id=17059297" rel="nofollow">https://news.ycombinator.com/item?id=17059297</a><p>This defines a do-over of exceptions in C++ in such a way that they can be implemented as return values, and lose the usual disadvantages of exceptions. Particularly with the optional bit in section 4.5, where you have to explicitly (but tersely) mark calls to functions which can throw, so you never have exceptions unexpectedly appearing out of nowhere.
I really dig the common lisp condition/restart system, where the callee defines different ways to recover from a failure, and the caller chooses which applies; or the caller can do their own thing with `unwind-protect`.
I cannot value if it is good or bad, but Go’s error handlig is really very verbose. On the one hand, it makes it quite easy to follow control flow but on the other hand it’s annoying to see an <i>if err != nil</i> on like every other line.
> Go has a unique approach to error handling, with a combination of explicit error values and an exception-like panic mechanism.<p>I don't think that's very unique in itself, although Go's particular quirks might be.
Something that seems to get forgotten in these discussions is that there’s a big difference at runtime between exceptions and error flag return values.<p>With error flags there’s a lot of code that runs all the time (although simple code with very predictable branches). A cycle or two in the common case, maybe tens of cycles for a branch mispredict in the error case.<p>Whereas exceptions (in the C++/Java style) are <i>free</i> when they don’t fire, but very expensive when they do -- hundreds or thousands of cycles to parse exception tables and unwind the stack.<p>Won’t anyone think of the runtime? :)<p>I tend to think exceptions are better language design since they give more freedom to use different implementation strategies. But of course that freedom isn’t really useful unless you know the programmer’s expectations about how often errors are likely to occur, and as others have noted that’s really the hard part of the problem.
Go's error handling is very annoying, or quirky, or inconsistent. I can't find the right word.<p>On the one hand you have to boilerplate EVERYTHING, check for errors ALL THE TIME. The benefit being "what's there is there. No magic data flows".<p>On the other hand you also have to write exception-safe code (BUT DON'T USE EXCEPTIONS!… at least not on purpose…).<p>Words exist to have meaning, and there's a precise and accurate word for what Go calls "panics", and that word is exceptions.<p>But most Go programs code as-if the language doesn't have exceptions, and thus don't write exception-safe code.<p>(and don't say that a panic should kill the task. fmt printer functions and HTTP handlers have their panics swallowed, so that's not a feasible assumption)
Haven't we realized yet that programs do not have a single flow of execution? each program has a few correct paths, and a few paths resulting from error.<p>Our languages so far pretend there is one correct path, and that the error paths are almost non-existence, or a nuesance at best.<p>In my opinion, what languages should do is the following, when an error happens: the program stops with an error report. There shouldn't be any errors caught ever. A faulty program should not be restarted; it should be fixed.