Proposal: Automatic Resource Management (original) (raw)

Roel Spilker r.spilker at gmail.com
Sat Mar 7 14:40:05 PST 2009

I'd really like to see getSuppressedExceptions() and addSuppressedException() in Throwable. This is also usefull in other scenario's as well. So maybe it is worth its own coin proposal. But then again, you'd get a dependency on that proposal. In that case I think it should be promoted to the body.

About the stacktrace: it isn't really part of the stack. And if the close method throws an exception in the finally block, and no other exception has been thrown, you would get the exception anyway, right? So I think there is no need for any of the suppressed exceptions to be part of the stacktrace.

Roel

On Sat, Mar 7, 2009 at 7:31 PM, Joshua Bloch <jjb at google.com> wrote:

I am not suggesting this. Most people have no need to look at these exceptions. Those who do can read them by calling the getSuppressedExceptions()method. If people think it's worth it, the stack trace printing code could be modified to include suppressed exceptions. In many cases, that would cause suppressed exceptions to be logged automatically. But I have some misgivings about this approach: I suspect there are programs that parse stack traces. While I frown on this behavior, and the spec does not guarantee that it works, I'd hate to be responsible for breaking these programs. What do others think of the "Retaining suppressed exceptions" feature? Should it be promoted to the body of the proposal? Should the suppressed exceptions be included in the stack trace? Thanks, Josh

More information about the coin-dev mailing list