On its own, seeing ‘SQLException‘ in method signature, does not provide you with information: “this is part of bigger transaction, and you have ability and responsibility to retry or rollback”.

That will be part of lib documentation, which should be read & understood regardless of existence of checked exception.

No. The transactional context is something the caller to the API knows. The person implementing the API that might fail on the SQL call doesn't know what's going on. That's why we would let the exception propagate.

> That will be part of lib documentation, which should be read & understood regardless of existence of checked exception.

First, checked exceptions *are* documentation for the lib. The best kind of documentation.

Second, really?

I would love to live in your world where people read documentation and where we all perfectly update the docs for everything. But both sides of this equation leave a lot to be desired in my world.

I don't read the documentation of most changes to most libraries. If I did that I would never get anything done. I can't even keep up with every commit that goes into the project I'm running. There are too many changes and too much code (I'm talking 30+ non-trivial merges per day).

> Let's say Java had no checked exceptions. I could just write IO code without doing a try since no one is forcing me to check anything.

Any decent C# linter will notice that the class exposes (IDisposable) and warn you that you should at least be wrapping it in a “using” block.

That's true for Java too. But that's only a part of the problem which is why I gave the second example.

Also, notice that a linter and a compiler error are different. I agree that people *should* always use a good linter and IDE. The reality is sadly far from that.