Throwable.addSuppressed error conditions -- use the exception as the cause?

Zhong Yu zhong.j.yu at gmail.com
Tue Apr 9 16:30:26 UTC 2013


On Mon, Apr 8, 2013 at 6:54 PM, Steven Schlansker <
stevenschlansker at gmail.com> wrote:

> Today I encountered "java.lang.IllegalArgumentException: Self-suppression
> not permitted" from Throwable.addSuppressed.
>
> My first surprise is that the try-with-resources block can throw this
> exception; it is very confusing to have auto-generated code throw
> exceptions.  But beyond that, it is impossible to figure out *which*
> exception caused the problem.  If you have multiple resources acquired in
> the try-with-resources, it could be any of them.
>
> Would it be reasonable to change
>
>     public final synchronized void addSuppressed(Throwable exception) {
>         if (exception == this)
>             throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE);
>
> to
>
>     public final synchronized void addSuppressed(Throwable exception) {
>         if (exception == this)
>             throw new IllegalArgumentException(SELF_SUPPRESSION_MESSAGE,
> this);
>
> so that when you get this exception it at least points to one of the throw
> sites that actually caused the problem?  Otherwise the only stack trace you
> have is in auto-generated code and you are left scratching your head,
> wondering where it came from.  I believe this would increase the
> debuggability of the try-with-resources construct and there's no
> immediately obvious downside.
>
> I'm not the only one who was confused by this behavior:
>
> http://stackoverflow.com/questions/12103126/what-on-earth-is-self-suppression-not-permitted-and-why-is-javac-generating-co
>
>
> Reusing exception is probably not a good idea - unless the exception is
immutable, i.e. enableSuppression=writableStackTrace=true.

Interestingly, even for an immutable exception, `e.addSuppressed(e)` isn't
allowed. I think that it should be allowed.

Zhong Yu



More information about the core-libs-dev mailing list