suppressedException semantics

David Holmes David.Holmes at oracle.com
Mon Aug 23 21:46:40 PDT 2010


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



More information about the coin-dev mailing list