Exceptions are often a better way to handle errors than returning them as values. We argue that traditional exceptions provide better user and developer experience, and show that they even result in faster execution.
The guy keeps on picking on Go, which is infamous for having terrible error handling, and then he has the nerve to even pick on the UNIX process return convention, which was designed in the 70s.
The few times he mentions Rust, for whatever reason he keeps on assuming that .unwrap() is the only choice, which’s use is decidedly discouraged in production code.
I do think there is room for debate here. But error handling is a hellishly complex topic, with different needs between among others:
short- vs. long-running processes
API vs. user-facing
small vs. big codebase
library vs. application code
prototyping vs. production phase
And even if you pick out a specific field, the two concepts are not clearly separated.
Error values in Rust usually have backtraces these days, for example (unless you’re doing embedded where this isn’t possible).
Or Java makes you list exceptions in your function signature (except for unchecked exceptions), so you actually can’t just start throwing new exceptions in your little corner without the rest of the codebase knowing.
I find it quite difficult to properly define the differences between the two.
But that’s what I mentioned regarding Java there. Java calls them “exceptions”, but generally forces the caller to either handle them or explicitly bubble them upwards…
The guy keeps on picking on Go, which is infamous for having terrible error handling, and then he has the nerve to even pick on the UNIX process return convention, which was designed in the 70s.
The few times he mentions Rust, for whatever reason he keeps on assuming that
.unwrap()is the only choice, which’s use is decidedly discouraged in production code.I do think there is room for debate here. But error handling is a hellishly complex topic, with different needs between among others:
And even if you pick out a specific field, the two concepts are not clearly separated.
Error values in Rust usually have backtraces these days, for example (unless you’re doing embedded where this isn’t possible).
Or Java makes you list exceptions in your function signature (except for unchecked exceptions), so you actually can’t just start throwing new exceptions in your little corner without the rest of the codebase knowing.
I find it quite difficult to properly define the differences between the two.
The handling is enforced by one while the other may be unknown to the person who calls the function. I think that’s a pretty clear difference.
But that’s what I mentioned regarding Java there. Java calls them “exceptions”, but generally forces the caller to either handle them or explicitly bubble them upwards…