suppressedException semantics

[Neal Gafter]

Brian Goetz wrote this on lambda-dev:

On Fri, Jul 16, 2010 at 10:07 AM, Brian Goetz <brian.goetz at oracle.com>wrote:

> And, given that inner classes [try blocks] *already* suffer from the
> accidental [exception] shadowing
> problem, creating a mechanism that goes the other way (even if the other
> way
> is absolutely right!) is even more confusing for Java developers, who now
> have
> to keep track of two separate and inconsistent bits of puzzlerhood.
>

(Editorial text added in brackets)

This argument appears to apply precisely as well to exception shadowing as
it does to name shadowing.

On Wed, Aug 25, 2010 at 5:58 PM, Joshua Bloch <jjb at google.com> wrote:

> FWIW, I do wish that Java's entire exception handling mechanism worked more
> like ARM's.  I was aware of this when I designed it.  But it's too late to
> change the semantics of what happens when an arbitrary exception is thrown
> when another one is already "on the stack."  I think we did the best we
> could under the circumstances.
>
>       Josh
>
> On Mon, Aug 23, 2010 at 9: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
> >
> >
>
>