Here is how Sun describes the cause facility: 

"A throwable ... can contain a cause: another throwable that caused this throwable to get thrown. The cause facility is new in release 1.4. It is also known as the chained exception facility, as the cause can, itself, have a cause, and so on, leading to a "chain" of exceptions, each caused by another..."

One of the earliest implementations of chained exceptions was "excuses" in Xanadu; see PromisePipelining.

------

I take the following issues with ChainedExceptions: In any modular system, there must be a certain amount of 'blinding' across component boundaries to prevent leaking implementation and thereby prevent binding to implementation. ChainedExceptions, unless explicitly discarded at component boundaries, will leak; good modularity properties should not require such explicit effort. Further, there is not much more the recipient can do with such an exception - other than log it and react to the most local failure - and even for this purpose the exceptions are of dubious value, since the error is being reported to the user of the code rather than the developer of it. If the intent is to report errors to the developer of the code, an IDE or debugger could easily annotate code to track error-flows - especially easy with PromisePipelining.

''Seems to be a thought similar to CheckedExceptionsAreOfDubiousValue.''

----
CategoryException