[materiallie]

Put another way: errors tend to either be handled "close by" or "far away", but rarely "in the middle".

So Java's checked exceptions force you to write verbose and pointless code in all the wrong places (the "in the middle" code that can't handle and doesn't care about the exception).

[Jensson]

> So Java's checked exceptions force you to write verbose and pointless code in all the wrong places (the "in the middle" code that can't handle and doesn't care about the exception).

It doesn't, you can just declare that the function throws these as well, you don't have to handle it directly.

[wavemode]

It pollutes type signatures. If some method deep down the call stack changes its implementation details from throwing exception A you don't care about to throwing exception B you also don't care about, you also have to change the type of `throws` annotation on your method.

This is annoying enough to deal with in concrete code, but interfaces make it a nightmare.

[pjmlp]

You mean like using Result with a long list of possible errors, thus having crates that handle this magically with macros?

[wavemode]

Yes, the exact same problem is present in languages where "errors are just values".

To solve this, Rust does allow you to just Box<dyn Error> (or equivalents like anyhow). And Go has the Error interface. People who list out all concrete error types are just masochists.

[pjmlp]

Go as usual, got this clever idea to use strings and having people parse error messages.

It took until version 1.13 to have something better, and even now too many people still do errors.New("....."), because so is Go world.