[kllrnohj]

It is laziness to an extent, sure, but that's a huge part of language design. We wouldn't use Java or C# or Python or any of these high level languages if we weren't lazy, after all, we'd be writing assembly like the silicon gods intended!

The problem with Java checked exceptions is they don't work well with interfaces, refactoring, or layering.

For interfaces you end up with stupid stuff like ByteArrayInputStream#reset claiming to throw an IOException, which it obviously never will. And then for refactoring & layering, it's typical that you want to either handle errors close to where they occurred or far from where they occured, but check exceptions forces all the middle stack frames that don't have an opinion to also be marked. It's verbose and false-positives a lot (in that you write a function, hit compile, then go "ah forgot to add <blah> to the list that gets forwarded along..." -> repeat)

It'd be better if it was the inverse, if anything, that exceptions are assumed to chain until a function is explicitly marked as an exception boundary.

[Terr_]

When I say lazy, I mean the essential work of modeling what's going on and making a decision which can only be made by a human. In this respect, choosing what exceptions-types to throw is like choosing what regular-types to return. If I return a GraphNode instead of a DatFile, then I should probably throw a GraphNodeException instead of a DatFileChecksumException.

Syntactic sugar should make it easier to capture the decision after it's been made. For example, like replacing "throws InnerException" (perhaps a leaky abstraction) with something like "throws MyException around InnerException".

[kllrnohj]

Yes but you only make those types of decisions on library boundaries, which is a relatively small amount of code. Meanwhile checked exceptions make all of the code harder to deal with in non-trivial ways (eg, the ubiquitous "Runnable" cannot throw a checked exception). And it's that everywhere-else where "laziness" won and checked exceptions died.