The very concept of "error handling" is absurd.<p>There are no errors, just unnecessary abstractions and control flow hacks.
You try to open a file; either you can or you cannot, and both possibilities are equally likely and must be handled by normal control flow in your program. Forcing an artificial asymmetry in the treatment of both cases (as championed by the error handling people) adds ugly complexity to any language that tries to do so.
There seems to be no mention of the Common Lisp condition system, which allows for handling of exceptional situations actually done right. Is this omission purposeful?<p>See <a href="https://news.ycombinator.com/item?id=23843525" rel="nofollow">https://news.ycombinator.com/item?id=23843525</a> for a recent long discussion about my upcoming book on the topic. (Disclosure: this is a shameless plug.)
> but without the downsides of the costly C++ memory deallocation on stack unwinding.<p>I.e. I don’t care about restoring the program to a known state when handling an error (memory deallocation is just one case of processing unwind blocks; locks need releasing,my file handles returned to kernel etc). This really only makes sense when your error “handling” is merely printing a user friendly error message and exiting.
> Composing Errors Codes ... Instead of sprinkling if statements, the error handling can be integrated into the type ... The check for errors is only done once.<p>That is only a superficial level of composition, if one can call it that at all, that doesn't account for actual composition of errors of different types. The example provided is just encapsulation and therefore orthogonal to the issue of error handling approaches. i.e. in the example, the error handling code is only centralized, not composed.
The only downside of error codes via Sum types (Rust) seems to be, according to the article, is performance. It then claims that Checked Exceptions are the solution (at least according to Joe Duffy).<p>Maybe I'm naive to how exceptions are actually implemented, but it seems to me that both a checked exception and Sum Type would incur the same overhead, a single branch to make sure things haven't exploded.
The obvious solution (in C++) is not to use exceptions at all, but make your own `error` and `expected<T>` class, and just add [[nodiscard]] to them. All the benefits of Go-style errors, you’ll never forget to check the error, and there is very little runtime overhead. If you pass the error as an out parameter then there is zero runtime overhead on success.
> Swift does not AFAICT provide mechanisms for enforcing checks of return types<p>Swift does this by default! You have to annotate (via @discardableResult) those functions which should <i>not</i> warn.<p>But of course try/catch is used in Swift more often.
There are 3 separate things that each require their different approach.<p>- errors i.e bugs made by programmer
- logical "error" conditions that the program is expected to handle for example network connection failed or user input failed
- unexpected error conditions that typically boild down to resource allocation errors, socket could not be allocated or memory allocation failed etc.<p>In my experience all of these are best handled with a different tool.<p>For bugs use an assert that dumps the core and leaves a clear stack trace.
For conditions that the program needs to handle use error codes.
And finally for the truly unexpected case use exceptions .
An important paper on the trade offs: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r0.pdf" rel="nofollow">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p070...</a>
Rust shines when doing error handling. No way to ignore errors, but properly handling them often adds just a single question mark to your code. Everything stays readable and lightweight.<p>Of course the error handling story is still perfectible but so far it's already one of the best I know.
No discussion is complete without mention of Erlang’s view on this<p><a href="https://erlang.org/download/armstrong_thesis_2003.pdf" rel="nofollow">https://erlang.org/download/armstrong_thesis_2003.pdf</a>