45

Is there a not so ugly way of treat the close() exception to close both streams then:

    InputStream in = new FileInputStream(inputFileName);
    OutputStream out = new FileOutputStream(outputFileName);

    try {
        copy(in, out);
    } finally {
        try {
            in.close();
        } catch (Exception e) {
            try {
                // event if in.close fails, need to close the out
                out.close();
            } catch (Exception e2) {}
                throw e; // and throw the 'in' exception
            }
        }
        out.close();
    }

update: All the above code is within one more try-catch, thanks for the warnings.

FINALLY (after the answers):

And a good utility method can be done using Execute Around idiom (thanks Tom Hawtin).

Community
  • 1
  • 1
The Student
  • 27,520
  • 68
  • 161
  • 264
  • 6
    Consider catching exceptions at the proper level of abstraction, e.g. IOException, etc. instead of the too vague Exception. – JRL Apr 23 '10 at 14:20
  • 1
    I think that for this case, don't matter which Exception is thrown. Or why would? – The Student Apr 23 '10 at 17:02
  • 3
    Please note that your code does not necessarily close `in`, see http://stackoverflow.com/questions/2441853/java-resource-management-please-help-to-understand-findbugs-results – meriton Apr 27 '10 at 21:11
  • See also: http://stackoverflow.com/questions/12552863/correct-idiom-for-managing-multiple-chained-resources-in-try-with-resources-bloc – Dave Jarvis May 04 '16 at 19:41

12 Answers12

56

This is the correct idom (and it works fine):

   InputStream in = null;
   OutputStream out = null;
   try {
       in = new FileInputStream(inputFileName);
       out = new FileOutputStream(outputFileName);
       copy(in, out);
   finally {
       close(in);
       close(out);
   }

  public static void close(Closeable c) {
     if (c == null) return; 
     try {
         c.close();
     } catch (IOException e) {
         //log the exception
     }
  }

The reason this works fine is that the exception thrown before you got to finally will be thrown after your finally code finishes, provided that your finally code doesn't itself throw an exception or otherwise terminate abnormally.

Edit: As of Java 7 (and Android SDK 19 - KitKat) there is now a Try with resources syntax to make this cleaner. How to deal with that is addressed in this question.

Community
  • 1
  • 1
Yishai
  • 90,445
  • 31
  • 189
  • 263
  • 6
    Note: this is not the correct idiom for all stream types. If the `OutputStream` buffers data (`BufferedOutputStream`) or it writes closing blocks (`ZipOutputStream`), you could lose data and the application would not handle it because it swallows exceptions. Logging is not a replacement for correct error handling. – McDowell Jun 15 '10 at 12:09
  • @McDowell, it is a good point regarding the output stream (see my comment to Adamski's answer that said something similar), however I would still say it is the standard idiom. – Yishai Jun 15 '10 at 15:04
  • Since this is the accepted answer and people will look at it - and since you agree with @McDowell please address his comment in your answer - -in the catch block – Mr_and_Mrs_D May 02 '13 at 21:16
  • @Mr_and_Mrs_D, I don't know, with Java 6 end of life, the real answer is to use the Java 7 options, it certainly will be soon enough. I am loath to remake answers that got upvotes and acceptance on a different premise. – Yishai May 02 '13 at 21:57
  • Right - but much of what is going will keep being Java 6 - Android for one thing... – Mr_and_Mrs_D May 02 '13 at 21:58
  • Using this method Sonar says : "Possible null pointer dereference of inputStream" , so how do you think Sonar is suggesting this be rewritten? – djangofan Oct 02 '15 at 00:30
32

You could implement a utility method:

public final class IOUtil {
  private IOUtil() {}

  public static void closeQuietly(Closeable... closeables) {
    for (Closeable c : closeables) {
        if (c != null) try {
          c.close();
        } catch(Exception ex) {}
    }
  }
}

Then your code would be reduced to:

try {
  copy(in, out);
} finally {
  IOUtil.closeQuietly(in, out);
}

Additional

I imagine there'll be a method like this in a 3rd party open-source library. However, my preference is to avoid unnecessary library dependencies unless I'm using a large portion of its functionality. Hence I tend to implement simple utility methods like this myself.

OscarRyz
  • 196,001
  • 113
  • 385
  • 569
Adamski
  • 54,009
  • 15
  • 113
  • 152
  • 1
    this is slightly different, as the in exception is not rethrown – Sam Holder Apr 23 '10 at 14:19
  • Nice idea, a var-arg of closeables. – Yishai Apr 23 '10 at 14:21
  • Actually I changed my mind as I don't agree with propagating the first Exception whilst ignoring subsequent ones. Better to suppress all exceptions given that this is simply relinquishing resources rather than an exceptional circumstance. – Adamski Apr 23 '10 at 14:22
  • 7
    I'd add a nullcheck. The closeable resource may not have been assigned. To the OP: the Commons IO library has similar methods: http://commons.apache.org/io/api-1.4/org/apache/commons/io/IOUtils.html – BalusC Apr 23 '10 at 14:22
  • 3
    You want to close the output stream "quietly"?! – Tom Hawtin - tackline Apr 23 '10 at 14:25
  • Why have they left the IOUtils constructor public in Commons I/O? Also, this looks out of date as they haven't referenced Closeable but have overloaded the closeQuietly method with multiple types (Writer, Reader, etc). – Adamski Apr 23 '10 at 14:28
  • @Adamski: "I don't agree with propagating the first Exception while ignoring subsequent ones" Agree, should subclass IOException with some ChainedIOException containing all the failures if really an exception has to be raised. – Matthieu BROUILLARD Apr 23 '10 at 15:22
  • +1 I modify the code a little bit to use the if/try idiom I saw in a James Gosling code years ago. – OscarRyz Apr 23 '10 at 17:05
  • 7
    Why would the Java developers raise an exception if it is just to be ignored? – The Student Apr 27 '10 at 20:04
  • @Tom Brito, although closing a stream is generally not an operation you want to get worked up about, logging the failure can be valuable. In some cases the correct closing is in fact what flushes the stream from a buffer and in fact things can go wrong there that are not "nothings." That is Tom Hawtin's point above. – Yishai Apr 27 '10 at 20:44
  • @Yishai so you agree with my choose of the right answer (not this) – The Student Apr 28 '10 at 14:08
  • @Tom Brito, since you chose my answer, I'm not going to argue ;-) – Yishai Apr 28 '10 at 14:48
19
try {
    final InputStream in = new FileInputStream(inputFileName);
    try {
        final OutputStream out = new FileOutputStream(outputFileName);    
        try {
            copy(in, out);
            out.flush(); // Doesn't actually do anything in this specific case.
        } finally {
            out.close();
        }
    } finally {
        in.close();
    }
} catch (IOException exc) {
    throw new SomeRelevantException(exc);
}

Remember that opening a stream may throw an exception, so you do need a try between the stream openings (please don't do some hack involving nulls. Anything can throw an Error (which are not an instances of Exception).

It turns out that catch and finally should rarely share the same try.

Since Java SE 7 you can write use try-with-resource to avoid so much indentation. It more or less does the same thing although there are suppressed exception hidden away.

try (
    final InputStream in = new FileInputStream(inputFileName);
    final OutputStream out = new FileOutputStream(outputFileName);    
) {
    copy(in, out);
    out.flush(); // Doesn't actually do anything in this specific case.
} catch (IOException exc) {
    throw new SomeRelevantException(exc);
}

You may want to use the Execute Around idiom.

I believe the standard good way to copy is using NIO's transferTo/transferFrom.

Community
  • 1
  • 1
Tom Hawtin - tackline
  • 145,806
  • 30
  • 211
  • 305
  • +1, that's identical (character-for-character) to the answer I was typing! :) – Adam Paynter Apr 23 '10 at 14:21
  • Very nice actually - could you please comment on the benefits of it compared to the accepted answer ? Also if say `copy(in, out);` and `out.close();` both throw won't we loose the exception thrown by `copy(in, out);` ? – Mr_and_Mrs_D May 02 '13 at 23:39
  • @Mr_and_Mrs_D Kind of. In practice unbuffered I/O streams do not throw `IOException` from `close`. Even if they did throw `IOException`, the control flow would be the same. / Java SE 7 adds suppressed exceptions. I don't expect anyone to search through the suppressed tree to find the right exception, which isn't even really theoretically possible to do locally as there is not a defined ordering on exception priority. – Tom Hawtin - tackline May 03 '13 at 10:16
  • Thanks - still wouldn't the answer be more complete if you caught the close() exception and log it ? – Mr_and_Mrs_D May 03 '13 at 14:36
  • Best answer here. You remembered to mention that it's a lot cleaner in Java 7, you don't have to remember that `close()` could also throw a `RuntimeException` (or any other `Throwable`), and the pattern works for locks, too. – David Ehrmann Jun 27 '15 at 17:51
  • @DavidEhrmann To be fair, the question was asked over a year before Java SE 7 was released. (I added that in the May 3 '13 edit.) – Tom Hawtin - tackline Jun 27 '15 at 18:25
8

Since Java 7 there is a much nicer way to write try-finally block in regards to Closeable resources.

Now you can create your resources in parenthesis after the try keyword, like this:

try (initialize resources here) {
   ...
}

And they will be closed automatically after the block of code is finished. There is no need for the finally part.

An example:

try (
   ZipFile zf = new ZipFile(zipFileName);
   BufferedWriter writer = Files.newBufferedWriter(outputFilePath, charset);
) {
    // Enumerate each entry
    for (Enumeration entries = zf.entries(); entries.hasMoreElements();) {
        // Get the entry name and write it to the output file
        String newLine = System.getProperty("line.separator");
        String zipEntryName = ((java.util.zip.ZipEntry)entries.nextElement()).getName() + newLine;
        writer.write(zipEntryName, 0, zipEntryName.length());
    }
}

And after the for loop is done, the resources will be closed!

Azri Jamil
  • 2,394
  • 2
  • 29
  • 37
darijan
  • 9,725
  • 25
  • 38
8

Guava has very nice IO APIs that eliminate the need for this. For instance, your example would be:

Files.copy(new File(inputFileName), new File(outputFileName));

More generally, it uses the concept of InputSuppliers and OutputSuppliers to allow the InputStreams and OutputStreams to be created within its utility methods, allowing it full control over them so it can handle closing properly.

Additionally, it has Closeables.closeQuietly(Closeable) which is basically the type of method most of the answers have suggested.

The IO stuff in it is still in beta and subject to change, but it's worth checking out and even using, depending on what it is you're working on.

ColinD
  • 108,630
  • 30
  • 201
  • 202
8

I strongly believe that in Java 7.0, you do not need to explicitly close the stream yourself anymore. Language Features in Java 7

try (BufferedReader br = new BufferedReader(new FileReader(path)) {
   return br.readLine();
}
vodkhang
  • 18,639
  • 11
  • 76
  • 110
  • When it's finally released, this will be terrific. You can specify multiple resources in the try(...) parameters, which are closed cleany for you by the JVM. – Sam Barnum Apr 23 '10 at 17:18
  • 3
    Although if the `BufferedReader` constructor fails (unlikely but does happen) you will leak. Also you are picking up the randomly confugured character encoding. – Tom Hawtin - tackline Jan 29 '11 at 14:36
5

You have, in commons io, in IOUtils, some closeQuietly methods.

Istao
  • 7,425
  • 6
  • 32
  • 39
2

One trick I sometimes use is to define a method called closeQuietly(Closeable) that tests to see if its argument is null then closes it, ignoring any exceptions. But you need to be a careful closing OutputStreams and Writers that way because they may actually throw an exception that matters; e.g. if the final flush fails.

Things are likely to improve with Java 7. Reports are that it will have a new construct that provides a more concise way of handling managed resources; e.g. streams that need to be closed when they are finished with.

Finally, you should be aware that your example has a bug. If the method call to open the second stream, the first stream will not be closed. The second open needs to be done inside the try block.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
1

In most cases the 'in' close() exception is irrelevant, so:

    try {
      copy(in, out);
    } finally {
    try {  in.close()  }  catch (Exception e) { /* perhaps log it */ }
    try {  out.close() }  catch (Exception e) {/* perhaps log it */ }
    } 

It's usually bad practice to swallow exceptions, but in this case I think it's ok.

leonbloy
  • 73,180
  • 20
  • 142
  • 190
0

Use

IOUtils.closeNoThrow(myInputStream);

Simple and elegant.

  • 2
    Probably you meant [IOUtils.closeQuietly](http://commons.apache.org/proper/commons-io/apidocs/org/apache/commons/io/IOUtils.html#closeQuietly(java.io.InputStream))? – Anton Savin Sep 17 '14 at 22:17
0

Here is my answer hopefully much better

https://stackoverflow.com/a/35623998/2585433

try {
    fos = new FileOutputStream(new File("..."));
    bos = new BufferedOutputStream(fos);
    oos = new ObjectOutputStream(bos);
}
catch (Exception e) {
}
finally {
    Stream.close(oos,bos,fos);
}


class Stream {

public static void close(AutoCloseable... array) {
    for (AutoCloseable c : array) {
        try {c.close();}
        catch (IOException e) {}
        catch (Exception e) {}
    }
  } 
}
Community
  • 1
  • 1
Noor Nawaz
  • 2,175
  • 27
  • 36
-2

In C#, there is using construction that closes closable objects automatically, when we leave the scope:

using(Stream s = new Stream(filename)) {
  s.read();
}

I think that this is a short form for java's try-finally block. Java 6 has introduced the Closable interface. So, using is almost there. When the final step is done in Java 7, it will be terrific indeed.

Val
  • 1
  • 8
  • 40
  • 64