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...
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...
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.
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.
Where people use things like anyhow.[0]
>forces you to handle it.
By writing `?`) And we get poor man's exceptions.
No, it's not quite the same. Checked exceptions force you to deal with them one way or another. When you use `?` and `anyhow` you just mark a call of fallible function as such (which is a plus, but the it's the only plus), and don't think even for a second about handling it.
If anything, `?` is better for actual "handling". It's explicit and can be questioned in a code review, while checked exceptions auto-propagate quietly, you don't see where it happens and where a local `catch` would be more appropriate. See the "Can you guess" section of the post. It discusses this.