The Error Model in Midori (joeduffyblog.com)
recommended by 1 user | 2016 | 146 points by jsnell | language design | original thread |
One user recommended this thread. What they said:
twic Aug 9, 2018 | on: On the uses and misuses of panics in Go | context

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.

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':

https://news.ycombinator.com/item?id=11054912

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! :)

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:

https://news.ycombinator.com/item?id=14823054

The most interesting thing i've read on this recently is the proposal for "Herbceptions" in C++:

https://news.ycombinator.com/item?id=17059297

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.