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).
That will be part of lib documentation, which should be read & understood regardless of existence of checked exception.