suppressedException semantics

[Alex Buckley]

I think the mail below was intended for coin-dev, not lambda-dev.

(Just to note that exceptions from the literal try-finally below aren't 
changed; what's new is suppression in the synthesized catch and finally 
blocks due to AutoCloseable variables.)

Alex

On 8/24/2010 1:02 AM, Paul Benedict wrote:
> Interest David! I never considered that the original exception should
> be thrown, and then just collect the suppressed exceptions. That's
> very interesting. As you point out, there's a difference between root
> cause vs. suppression. Perhaps what you pointed out is just crazy
> enough to work. :)
> 
> Paul
> 
> On Mon, Aug 23, 2010 at 11: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
>>
>>
>