suppressedException semantics

[David Holmes]

Reinier Zwitserloot said the following on 08/24/10 20:20:
> I get the feeling Paul Benedict is saying the opposite of what David
> Holmes is saying, which is a bit confusing. Paul: David is suggesting
> that the original exception should NOT be thrown in the new trywith
> construct, to mirror the behaviour of what happens in existing
> try/finally blocks.

I haven't seen Paul's mail as I just started subscribing. Sorry if I 
seem to be changing the tack of an ongoing discussion. These are just my 
views.

> David: The idea behind throwing the original and tacking on any
> further exceptions as suppressed ones is because the original one is
> simply better. If for example a network connection fails due to for
> example a broken pipe, the original exception will say so. If I then
> close a bunch of resources related to the socket, all sorts of
> further exceptions will fall out, mostly based around the notion that
> the entire socket has become invalidated. These may no longer state
> the original reason for the failure of the socket (broken pipe).
> Also, the point at which the socket broke, is when the original
> exception occurred. Its stack trace is the best one, of all traces of
> all thrown exceptions, in that its closest to the actual state of the
> stack at the time the problem occurred.

But does it really matter as long as the less-better exception reports 
the original better one? This would be just like the way the "cause" 
works today - the final exception is not the key one, but the one that 
caused it. I see the trywith proposal as running counter to try-finally 
and to the current "caused-by" semantics. As long as the exception you 
catch will print or otherwise make available the chain of exceptions, 
then you have what you need. In which case a simpler mechanism that is 
consistent with existing language and API features is preferable in my view.

> Of course, tweaking how standard try/finally works where the finally
>  block throws its own exception is not possible, because that would
> break backwards compatibility. There is indeed a slight inconsistency
> in having trywith work differently from try/finally, but in
> retrospect, if suppressedexceptions had been available from oak 1.0,
> having the exception in the try block be 'more important' than
> further exceptions is clearly the right way to go. Thus, where we can
> switch to the better option without breaking backwards compatibility,
> we do, and where we can't, we don't. Seems reasonable to me.

Well I disagree that the exception in the try block is necessarily more
important than the one in the finally block. The flaw in 1.0 was that
you lost the first exception.

Cheers,
David
> 
> --Reinier Zwitserloot
> 
> 
> 
> On Tue, Aug 24, 2010 at 6:46 AM, David Holmes
> <David.Holmes at oracle.com <mailto: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
> 
>