The problem is that if some code you call throws a checked exception (InterruptedException being an extremely common culprit) then you must wrap... and suddently nobody calling YOUR code can catch that InterruptedException reliably because it's now a SomeException (doesn't even have to be RuntimeException specifically) with an added "suppressed" exception that you now have to check for.

... so the basic "catch" syntax starts to fall apart because now you have to catch everything and resort to stuff like Guava's Throwables helpers.

It's madness.

The problem ultimately is variance: Methods are covariant, but throws clauses must be contravariant.

There are ways to solve this but "checked exceptions" (as in Java) are not the right way. Ask anyone who's worked in Scala on the JVM which they prefer and you'll have your answer.

It's possible to use a type parameter in a throws clause in Java, last I checked (as I also mentioned in more detail above). But it doesn't seem to be common practice, so interop is still a disaster.

That only works up to one checked exception type, because Java doesn't have anonymous union types.

It really is a lose-lose unless Java grows a more powerful system around this.

Sorry. This is nonsense. map() is the bread and butter of any program. Besides, you cannot ever decide whether an exception is important or not -- it's always in the purview of the user.

Re-throwing a non-checked exception is what I described as the usual / typical coping mechanism in languages with checked exceptions. Which is obviously a way to negate the whole feature.

Sorry, disagree. map() didn't even exist in Java until recently. It is convenience at the cost of some safety. If you're writing a non-critical or throw away code you may not care about strong guarantees. Personally I prefer strong guarantees over convenience. I would only use map() for things that can't throw checked exceptions. A for loop isn't that hard to write.