suppressedException semantics

[Joe Darcy]

David Holmes 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. 

Just to be clear on the proposal, in the code example two exceptions are 
thrown and only one, B, propagates out.  All information about the 
existence of A is lost.

The proposal could, but does *not*, change the semantics of try-finally 
*without* a resource so that A was listed as a suppressed exception of B.

> 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.

Yes, the current semantics of try-with-resources is that the first 
exception thrown wins in terms of getting propagated out.  This is 
opposite to the try-finally case above.

>  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?

In my estimation, the first exception thrown is the one most likely to 
be information of what exactly went wrong as opposed to just being a 
cascading consequence of prior exceptions/problems.

>  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
>
>   

First-thrown-exception wins and last-thrown-exception wins are two 
simple and predictable polices toward handling suppression.  I find "I'm 
a worse problem then you" logic at each point along the way unappealing 
since it would be hard to know what throwable would eventually come 
out.  Of two errors, which is worse?  Is a checked exception worse than 
a runtime exception?  Is a non-error, non-java.lang.Exception Throwable 
worse than an Error? ...

-Joe