If you forget to handle a C++ exception you get a clean crash. If you forget to handle a C error return you get undefined behavior and probably an exploit.
Exceptions are more robust, not less.
Exceptions are more robust, not less.
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...
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.
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.
So clean that there's no stack trace information to go with it, making the exception postmortem damn near useless.