> Exceptions have the good property that they can't be ignored - if they're not handled, you get a reasonable program termination.
This would probably be the main point where I'd disagree. To get the same guarantees as you currently have, the exceptions would have to be checked exceptions like in Java. And, in contrast, the advantage (to me) here is that all error handling in Rust basically works like handling anything else.
Personally, I'm rather fond of the way Rust does it. Which surprised me, coming from a dynamic background.
Checked exceptions turn error handling into nearly almost the multiple-return handling that Rust has. In my opinion, to achieve big advantages that exceptions offer, you should only have a small number of try/catch blocks. You only catch when you can reasonably expect to handle the error and that's it.
Checked exceptions make you check for errors almost everywhere. Rust makes you check everywhere. They're almost the same thing. But I'll take Rust's method over checked exceptions any day; all is better than almost all. And for the type of projects Rust is built for, it's the right choice. But for error handling in general, if you don't care about the cost, unchecked exceptions are superior to both.
Can you clarify this? Your first paragraph seemed to contradict your 2nd one -- I think I must have misunderstood you somewhere.
I thought paragraph 1 boiled down to: "you shouldn't see any error handling code most places; only at the top."
Then in the 2nd paragraph, I interpret "all is better than almost all" as: "I want to be forced to check all exceptions all the time, not just a few. (Meaning, I want error handling code everywhere)."
Again, not being argumentative. Just asking for clarification.
There are 3 options: unchecked exceptions, checked exceptions, and error returns.
Exceptions have some advantages and disadvantages; the advantages are what I said above about only needing to write small amount of code. The disadvantages are that it does have some compiled code-size, performance, and language runtime requirements.
The nature of Rust sort of precludes it's use of exceptions and instead they have a reasonable error return facility that is a pretty type-safe way of forcing you to handle or propagate errors. Smaller compiled code, not much performance overhead, and it's easy to reason about because it's consistent. Of course, it's also a lot more boilerplate code to write.
Checked exceptions, on the other hand, negate the advantages of exceptions and still have all the other disadvantages of exceptions. It's also a lot harder to reason about than Rust's model of just handling all errors manually.
This would probably be the main point where I'd disagree. To get the same guarantees as you currently have, the exceptions would have to be checked exceptions like in Java. And, in contrast, the advantage (to me) here is that all error handling in Rust basically works like handling anything else.
Personally, I'm rather fond of the way Rust does it. Which surprised me, coming from a dynamic background.