suppressedException semantics

[Joshua Bloch]

FWIW, I do wish that Java's entire exception handling mechanism worked more
like ARM's.  I was aware of this when I designed it.  But it's too late to
change the semantics of what happens when an arbitrary exception is thrown
when another one is already "on the stack."  I think we did the best we
could under the circumstances.

       Josh

On Mon, Aug 23, 2010 at 9:46 PM, David Holmes <David.Holmes at oracle.com>wrote:

> I realize that I am late to the game here but reading Joe's latest ARM
> proposal (and having looked into the issues with pre-allocated
> exceptions) I find that the semantics of suppressed exceptions for
> try-with-resources are actually the opposite to what I initially thought.
>
> Taking regular Java as it stands, given:
>
> try {
>   throw new A();
> }
> finally {
>   throw new B();
> }
>
> the try-finally will always complete by throwing B and the fact that A
> occurred has been lost. Exception B has suppressed exception A in this
> case. So I thought that the addition of suppressedExceptions was a way
> for B to indicate that it has suppressed A. This could be considered a
> general language extension independent of try-with-resources: it is
> simply a way for exceptions that would be lost to be "chained" to the
> exception that replaced them. (And in such an extension I probably would
> not make addSuppressedException a generally available API.)
>
> What try-with-resources proposes is actually suppressing B (when it
> comes from an AutoCloseable) and propagating A. I find this somewhat
> confusing, especially when the argument of whether to suppress only
> Exception but not Error etc is taken into account. It is not apparent to
> me why the exception from the try block is more important than the
> exception from the finally block? As long as A can be found from B does
> it matter which is actually thrown? I would suggest that the
> try-with-resources code transformation would be a lot simpler if it did
> not change the exception that would naturally be thrown from the finally
> clause. It would also make it a moot point whether to distinguish Error
> from Exception etc.
>
> I just can't help but think that this is more complex than it needs to
> be. And at the same time that the "suppressed exception" mechanism is
> not as generally useful as it could be.
>
> And yes I've just donned my flak-jacket ;-)
>
> Cheers,
> David Holmes
>
>