If you want to exit the program because the error can't be handled (similar to an unhandled exception), rust has a different concept for it, panics, and any Result can be turned into a panic via `unwrap()`.

IMO both are important: panics represent unrecoverable errors, while Results can be acted upon (for instance, if read() returns Err(EINTR), you'll want to retry the read)

[0]: Granted, you need to write some boilerplate to get the backtrace on error creation.

[1]: You can cast all errors to `Box<dyn Error>`, a heap-allocated dynamically dispatched Error type.

> I never understood the love for Either-based error handling in Haskell and other languages.

What does a function that doesn't error look like under try-catch? How do you tell it apart from a function that can error.

It's the same argument as null/Optional. Yes, Optional behaves the same as a nullable value; the point is that languages with Optional allow you to have values that aren't nullable.

By the empty throws clause.

Three major problems: they interact inconsistently with generics, you can no longer take a function's result and store it as a value, and you still can't tell whether a function might throw by looking at the point where it's called.

A good version of exception specifications would be lightweight syntax sugar over either (in the same way that a good version of async/await is a lightweight syntax sugar over futures/promises). But I'm not aware of any language implementing that; I guess once you have working Either there's not enough value in providing an alternative syntax for it.

For system failures it's ok because the only handling you're going to do is retry at high level (and so even languages with an Either-oriented style tend to have some form of "panics" or exceptions for that kind of failure). But it can be a real problem when that also happens for "normal failure" paths like bad user input where you want to actually have business logic that handles and perhaps recovers from the failure.

If a method can fail on IO that's different than if it cannot fail. And the surrounding code has to account for that.

So, you might think that the methods are interchangeable if the error type is not present in the signature but this is actually wrong. Different failures have to be handled differently.

(I assume that you are /not/ talking about valid error cases in the problem domain that also might have to be handled)