> There is no magic language trick that can prevent you from having to rerun all tests for your software if you update a dependency. Pretty much period.

Of course, but having a checked exception (even better, having the errors be part of the return type via Result<T, E> or Option<T>) solved an entire class of problem. Doesn't mean that there aren't others of course. But surely this is a win?

>inb4 it makes the code very complex with nested return type Result<Result<Result<T, FileNotFoundError>,ReadError>, ParseError>

Then it was just hidden from you before. The complexity had always been there, it just never occurred to you that it can happen.

> But surely this is a win?

Not when it creates more issues than it solves, which checked exceptions do.

Checked exceptions are an entire side channel to the type system which breaks any sort of composition or genericity.

Maybe this is solvable, but Java seriously poisoned that well because its implementation is so shit, and if you’re looking for this static safety, first the rest of a Java-style type system does not justify it (there’s so many low hanging fruits), and second a result-style things will already give you the same benefits in a form which is known to work.

Ish? It is all too often that, at the point where you would be forced to catch the exception, the best path forward is to signal it to the user and see if they have a plan. Unfortunately, the only mechanisms we allow for that in modern systems is to unwind the entire stack to get to the call that came from a user. And whether done with chained return values, or with exceptions, the code will get to be a mess.

Signals that don't unwind can have their own problems, of course. I don't mean that as a silver bullet. But all too often the exceptions and error conditions that we use to teach these ideas are far more difficult because of our insistence on unwinding the stack. Neither return values nor exceptions change that.

If someone added an extra parameter to a function you're calling, when would you want to be alerted about it? At compile time? Or when you rerun all the tests?

Hopefully, your answer is compile time. If so can you now understand why you would want to be alerted about a new exception getting thrown at compile-time as well?

I'd like to think that, as an industry, we would move to libraries being foundational code, such that they don't change in fundamental ways. If a parameter is added, it should be done in a backwards compatible way, such that I don't have to know about it. The old behavior would continue to work.

As such, any breakage from calling would be, by definition, a bug. And no, we have not found a way to prevent bugs.

> If so can you now understand why you would want to be alerted about a new exception getting thrown at compile-time as well?

The library code can already throw anything. OutOfHeap, over/underflow, div0, stackoverflow, threadinterrupted. The caller already knows the function can throw, and documenting one more flavour of throw doesn't tell the caller anything.

> documenting one more flavour of throw doesn't tell the caller anything

but it does, in cases when there are errors that can or should be retried. Like a whitelist of documented cases where recovery and retry are possible, and of course all this infinite runtime stuff that can happen unexpectedly, for which there is no immediate solution.