Comment by Expurple
15 hours ago
You should compare exceptions to Result-style tagged unions in a language with exhaustiveness checks, like Rust. Not to return codes in C, lmao.
Everyone (except Go devs) knows that those are the worst. Exceptions are better, but still less reliable than Result.
https://home.expurple.me/posts/rust-solves-the-issues-with-e...
Rust is better here (by a lot), but you can still ignore the return value. It's just a warning to do so, and warnings are easily ignored / disabled. It also litters your code with branches, so not ideal for either I-cache or performance.
The ultimate ideal for rare errors is almost certainly some form of exception system, but I don't think any language has quite perfected it.
> you can still ignore the return value
Only when you don't need the Ok value from the Result (in other words, only when you have Result<(), E>). You can't get any other Ok(T) out of thin air in the Err case. You must handle (exclude) the Err case in order to unwrap the T and proceed with it.
> It also litters your code with branches, so not ideal for either I-cache or performance.
That's simply an implementation/ABI issue. See https://github.com/iex-rs/iex/
Language semantics-wise, Result and `?` are superior to automatically propagated exceptions.
> like Rust
Where people use things like anyhow.[0]
[0] https://docs.rs/anyhow/latest/anyhow/
Anyhow erases the type of the error, but still indicates the possibility of some error and forces you to handle it. Functionality-wise, it's very similar to `throws Exception` in Java. Read my post
As a matter of fact I did when it appeared on hn.
>forces you to handle it.
By writing `?`) And we get poor man's exceptions.
1 reply →