suppressedException semantics

Paul Benedict pbenedict at apache.org
Tue Aug 24 01:02:26 PDT 2010


Interest David! I never considered that the original exception should
be thrown, and then just collect the suppressed exceptions. That's
very interesting. As you point out, there's a difference between root
cause vs. suppression. Perhaps what you pointed out is just crazy
enough to work. :)

Paul

On Mon, Aug 23, 2010 at 11: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 lambda-dev mailing list