suppressedException semantics (original) (raw)

Neal Gafter neal at gafter.com
Thu Aug 26 17:10:02 PDT 2010

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 > >

More information about the coin-dev mailing list