This approach is great when:
* program requirements are clear
* correctness is more important than prototyping speed, because every error has to be handled
* no need for concise stack trace, which would require additional layer above simple tuples
* language itself has a great support for binding and mapping values, e.g. first class monads or a bind operator
Good job by the author on acknowledging that this error handling approach is not a solver bullet and has tradeoffs.
Call it a thought experiment. We start with a clean implementation that satisfies requirements. It makes a bold assumption that every star in the universe will align to help us achieve to goal.
Now we add logging and error handling.
Despite my best intentions and years of experience, starting with clean code, the outcome was a complete mess.
It brings back memories when in 2006 I was implementing deep linking for Wikia. I started with a "true to the documention" implemention which was roughly 10 lines of code. After handling all edge cases and browser incompatibilites I ended up with a whooping 400 lines.
Doing exactly the same as the original lines did, but cross compatible.
In my experience I've used exceptions for things that really should never fail, and optional for things that are more likely to.
> The most common approach is the traditional try/catch method.
teddyh•4h ago
Well, IIUC, Java had (and still has) something called “checked exceptions”, but people have, by and large, elected to not use those kind of exceptions, since it makes the rest of the code balloon out with enormous lists of exceptions, each of which must be changed when some library at the bottom of the stack changes slightly.
remexre•4h ago
Rust needs a bit more boilerplate to declare FooError, but the ? syntax automatically calling into(), and into() being free to rearrange errors it bubbles up really help a lot too.
The big problem with Java's checked exceptions was that you need to list all the exceptions on every function, every time.
esafak•4h ago
https://blogs.oracle.com/javamagazine/post/java-sealed-class...
keybored•4h ago
esafak•3h ago
keybored•4h ago
In surprising twist: Java has ConcurrentModificationException. And, to counter its own culture of exception misuse, the docs have a stern reminder that this exception is supposed to be thrown when there are bugs. You are not supposed to use it to, I dunno, iterate over the collection and bail out (control flow) based on getting this exception.
eadmund•3h ago
I hate checked exceptions too, but in fairness to them this specific problem can be handled by intermediate code throwing its own exceptions rather than allowing the lower-level ones to bubble up.
In Go (which uses error values instead) the pattern (if one doesn’t go all the way to defining a new error type) is typically to do:
which returns a new error which wraps the original one (and can be unwrapped to get it).A similar pattern could be used in languages with checked exceptions.