Proposal: Automatic Resource Management

[Roel Spilker]

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