Yeah, it's interesting how some people think that its axiomatic that checked exceptions are so awful where they're a feature I really value. <shrug>

Every modern Java library I’m aware of, avoids checked exceptions. Java itself recently introduced UncheckedIOException to wrap IOException in a few places. So while it’s not an official deprecation, it’s a sign that something’s not quite right.

Those are just objective facts. I, personally, don’t like this feature either. May be with very different language design it could be better, but as it is, it’s ergonomics is awful IMO. And I have problems to imagine how to rework it to make it work.

Well, arguably Java’s implementation is not the best regarding checked exceptions. Nonetheless I feel we threw the baby out with the bath water here, as a non-inheritance based checked exception system was not really tried and I feel it would be the best of both words. Since in the end, checked exceptions are just Result types which happens to be natively “understood” by the language - it gets stack trace support, auto-unwraps and bubbles up.

What's missing in Java is the ability for methods to abstract over the set of exceptions thrown by the methods it calls, via generics, for morethan a single exceptikn type. This would in principle be possible, similar to variadic template parameters in C++, and would solve the problem for lambdas and Streams etc. It's a bummer that Java doesn't provide this at present.

Java developers are really divided on the topic of checked exceptions, there is no consensus.

Adding or removing checked exceptions breaks library users in very painful ways: if you can’t handle an exception, you should rethrow, but this means a wavefront of code breakage downstream, so the library gets pinned and is never upgraded.

The solution to this is exception wrapping, and designing useful exception types in the first place. This is not an issue.

If it wasn’t, libraries would use checked exceptions, and they aren’t.