Half an email. Sorry. Complete:
That is probably ok for an InputStream but it is definitely not for
an OutputStream. If there is buffering going on, flush will get called
via the close method, triggering an exception and your data would not
have been written. With your example you would never find that out.
You only want to swallow an exception thrown from close if there was
an exception from the try. I would recommend writing something like:
class CloseException extends RuntimeException {
final IOException closed;
public CloseException(IOException tried, IOException closed) {
super(tried)
this.closed = closed;
}
public CloseException(IOException closed) {
super(closed)
}
public IOException getClosed() { return closed; }
}
interface UsingOutputStream<T> {
T use(OutputStream os);
}
class WithOutputStream {
public static <T> T blah(UsingOutputStream<T> action) {
OutputStream os = new BlahOutputStream();
IOException tried = null;
try {
action.with(os);
} catch (IOException e) {
tried = e;
} finally {
}
}
private static void close(OutputStream os, IOException) {
try {
os.close();
} catch (IOException e) {
throw new RuntimeException(e);
}
}
}
On Wed, Jun 3, 2009 at 3:10 PM, Mark Hibberd <mthibb...@gmail.com> wrote:
> Half an email. Sorry. Complete:
>
>
> That is probably ok for an InputStream but it is definitely not for
> an OutputStream. If there is buffering going on, flush will get called
> via the close method, triggering an exception and your data would not
> have been written. With your example you would never find that out.
>
> You only want to swallow an exception thrown from close if there was
> an exception from the try. I would recommend writing something like:
>
>
> class WithOutputStream {
> public static <T> T blah(UsingOutputStream<T> action) {
> OutputStream os = new BlahOutputStream();
> try {
>
> } catch {
>
> } finally {
>
> }
> }
> }
>
> class
>
> On Wed, Jun 3, 2009 at 12:55 PM, Christian Catchpole
> <christ...@catchpole.net> wrote:
>>
>> 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 <javaposse.t...@spamgourmet.com> 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 javaposse@googlegroups.com
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
