I get to agree with Max again.
Often the whole point of exception chaining is to allow you to decouple the different layers in a system, while still allowing for effective stack trace reporting. Expecting programmers to document underlying exceptions would defeat this purpose. Now, there may be some cases where you wish to volunteer additional info about certain common causes of exceptions; that may be OK. I've never seen a need, but I suppose it could happen. And I'd never make any pretense of having made an exhautive list of possible underlying exceptions - that would restrict options too much later, when you want to refactor the underlying layers. E.g. I might say "One common cause of DBException is a ConnectException, which can often be handled by attempting this operation again after a brief delay." But I'd never rule out the possibililty that it's some other completely different exception.