Re: different try-finally approach
Mike Schilling wrote:
Bill McCleary wrote:
Mike Schilling wrote:
Bill McCleary wrote:
finally
{
if (foo != null) foo.close()
if (bar != null) bar.close()
if (baz != null) baz.close()
}
}
This is not quite good enough when (as with streams or readers),
"close()" can itself throw.
In actual practice I tend to have a utility method like this somewhere
in a project that uses lots of I/O:
public static void close (Closeable c) {
if (c != null) {
try {
c.close();
} catch (IOException e) {
// Ignore.
}
}
}
which gets rid of the (IMHO useless) close() exceptions, and also
allows nulls (which it ignores).
The exceptions are pretty useless if you're done reading a stream. If
you're done writing one, they might be telling you that output wasn't
flushed correctly, which is a bad thing to ignore.
Explicitly calling flush() on an OutputStream at the end of the try
block should suffice to take care of that, shouldn't it? If it's gonna
throw while flushing, it will then throw in the try block.