suppressedException semantics

[Reinier Zwitserloot]

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.

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.

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.


 --Reinier Zwitserloot



On Tue, Aug 24, 2010 at 6:46 AM, 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
>
>