3 ms·
Rust's error handling is roughly isomorphic to the Platonic ideal of checked exceptions. In both cases you're forced to deal with (recoverable) errors and you
by rectang 4y ago
Rust's error handling is roughly isomorphic to the Platonic ideal of checked exceptions. In both cases you're forced to deal with (recoverable) errors and you know which lines of code can produce (recoverable) errors and which cannot.
However, the problem is that Java didn't implement checked exceptions well, as Joe Duffy articulated.
https://joeduffyblog.com/2016/02/07/the-error-model/#checked-exceptions https://joeduffyblog.com/2016/02/07/the-error-model/#checked...
> 1. Exceptions are used to communicate unrecoverable bugs, like null dereferences, divide-by-zero, etc.
> 2. You don’t actually know everything that might be thrown, thanks to our little friend RuntimeException. Because Java uses exceptions for all error conditions – even bugs, per above – the designers realized people would go mad with all those exception specifications. And so they introduced a kind of exception that is unchecked. That is, a method can throw it without declaring it, and so callers can invoke it seamlessly.
> 3. Although signatures declare exception types, there is no indication at callsites what calls might throw.
> [...]
The divide in Rust between recoverable Errors and unrecoverable panics is much cleaner (even if it's impossible to get right in every detail).
- illiarian 4y agoI tink unrecoverable panics in Rust and Go are a bad design decision. There are very few situations (if any) where you want a completely unrecoverable error. At the very least you'd want to log it somewhere. No wonder there's a `catch_unwind` in Rust since 1.9 and `set_hook` since 1.10 to try and awkwardly work around this design.