suppressedException semantics

[David Holmes]

Reinier Zwitserloot said the following on 08/24/10 22:42:
> Yes, it really matters. No current tools are capable of reporting 
> suppressed exceptions.

I don't see how the lack of tools is relevant to the question. You will 
want to follow the chain of exceptions no matter which one is chosen to 
be thrown.

> Between the causality chain and each exception in 
> it having suppressed exceptions, with all of THOSE potentially also 
> having a causality chain and further suppressed exceptions, a single 
> problem can result in many tens of stack traces. Making sure there is 
> such a thing as the primary trace amongst the set, and making sure that 
> the odds are good this one exception trace is more useful than the 
> others, is obviously (to me, anyway), a worthwhile endeavour, and is 
> certainly worth a little inconsistency.

It is far from obvious to me that if there are "many tens of stack 
traces" then there even exists a "primary" one, let alone that that will 
be the exception being thrown under the current proposal.

Once you have the possibility of suppressed exceptions then for any 
exception thrown you need to follow the chain. If you do that then you 
will see the full picture. In which case there is no need to have 
semantics that run counter to existing language exception semantics.

YMMV.

David Holmes

> 
>  --Reinier Zwitserloot
> 
> 
> 
> On Tue, Aug 24, 2010 at 1:10 PM, David Holmes <David.Holmes at oracle.com 
> <mailto:David.Holmes at oracle.com>> wrote:
> 
>     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>
>         <mailto: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
> 
> 
>