Yeah, this can be a problem. Perhaps the neatest way is to do
something like this.. use a static helper which eats the exception.
OutputStream os = new BlahOutputStream();
try {
// do stuff hyar, hyar and hyar..
os.write( stuff );
} finally {
StreamHelperThingy.closeDontThrow(os);
}
On Jun 3, 10:01 am, Tim <[email protected]> wrote:
> In Joshua Bloch's Automatic Resource Management proposal
> (http://docs.google.com/Doc?id=ddv8ts74_3fs7483dp) for project Coin he
> wrote:
>
> Even the "correct" idioms for manual resource management are
> deficient:
> if an exception is thrown in the try block, and another when
> closing the
> resource in the finally block, the second exception supplants the
> first, making it difficult to determine the real cause of the
> trouble.
> In other words, by responsibly closing your resource even during
> some
> catastrophic event, you can actually erase all record of the
> event,
> resulting in many wasted hours of debugging. While it is possible
> to
> write code to suppress the second exception in favor of the first,
> virtually no one does, as it is just too verbose. This is not a
> theoretical problem; it has greatly complicated the debugging of
> large
> systems.
>
> I just encountered this problem: Some code threw an exception creating
> a zip.
> The ZipOutputStream was closed in a finally block and the real
> exception
> was replaced by one complaining that there were no entries in the zip.
>
> Does anyone do the "right" thing? What are the best idioms or helper
> methods/classes to do this?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
