Re: different try-finally approach

From:

"Mike Schilling" <mscottschilling@hotmail.com>

Newsgroups:

comp.lang.java.programmer

Date:

Mon, 3 Aug 2009 20:11:48 -0700

Message-ID:

<h589c1$120$1@news.eternal-september.org>

Bill McCleary wrote:

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.

Probably. If you're writing to a file, I wouldn't guarantee that the
directory entry is fully updated until the file is closed.

If you're going to write helper methods to simplify this, why not
something like (neither compiled nor tested, and I wouldn't vouch for
"thought through")

public static void close(Closeable... c) throws IOException
{
    List<IOException> exceptions = new ArrayList<IOException>();
    for (Closeable cl : c)
    {
        try { cl.close()
        } catch (IOException ex) {
            exceptions.add(ex) }
    }
    if (exceptions.size() > 0)
        throw new WrappedIOException(exceptions);
}