Throwable.addSuppressed error conditions -- use the exception as the cause? (original) (raw)

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(SELFSUPPRESSIONMESSAGE); to public final synchronized void addSuppressed(Throwable exception) { if (exception == this) throw new IllegalArgumentException(SELFSUPPRESSIONMESSAGE, 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