suppressedException semantics

[David Holmes]

Hi Joe,

Joe Darcy said the following on 08/25/10 04:41:
> 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.

Yes.

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

Yes again. While not currently proposed it would seem to me that 
suppressedExceptions should be applied to the existing try-finally case 
to fix that long standing hole/wart/imperfection in the language.

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

I can buy that in the simple one-resource case, particularly for the 
classic I/O examples. But it isn't an absolute truth and once multiple 
resources and layers of exceptions are involved then I don't think there 
can reasonably be a general notion of which is "more important" or "more 
informative". In general this can only be answered in context - as per 
your comments below. So while I can see some merit in the simple common 
use-case acting the opposite of existing try-finally semantics, I don't 
think this "scales" so to me the inconsistency and added complexity is 
not worth the benefit supplied to that simple use-case.

As always YMMV.

Cheers,
David Holmes

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