public class CloseableTemplate {
..public void execute(CloseableCallbackHandler callbackHandler, T closeable) {
….try {
……callbackHandler.doWithCloseable(closeable);
……// close reader normally, we are interested whether or not this fails.
……reader.close();
….} catch(Exception e) {
……close(closeable);
……// rethrow as runtime
……throw new CustomRuntimeException(e);
….}
..}
..private void close(Closeable closeable) {
….try {
……if(closeable != null) {
……..closeable.close();
……}
….} catch(IOException e) {
……log.info(\\\”closing reader failed but since there is another exception that occurred first we only log this one.\\\”, e);
….}
..}
}

public void copyFile() throws IOException {
..BufferedReader reader = null;
..try {
….reader = new BufferedReader(new FileReader(“foo.txt”));
….String line = null;
….while((line = reader.readLine()) != null) {
……String formattedLine = Parser.parseLine(line);
….}
….// everything fine here: NO exception!
..} finally {
….try {
……// now reader.close() throws an exception
……reader.close();
….} catch(IOException e) {
……log.info(“closing reader failed and my caller will never know!”, e);
….}
..}
// return normally without any exception
}

Thanks for your comments.

@1: I don’t consider logging an Exception the same as swallowing. I consider swallowing to be empty catch blocks and in case you “miss” an exception due to the reason I described in my blog.
Like I said maybe logging on info level is not the best option but at least it will be looked at by the application maintainer (at least you hope ).
Personally I would not propagate the IOException that occurred for closing a resource all the way up to the end user. What can he do about it?

@2: true that’s why I guess you need solid finally blocks.

@3: true, but I hope I showed that with little effort or even less effort in case of the Template approach you can save yourself a lot of problems in those “hardly” cases.
(It is less because you only have to create the Template once and can use that throughout you application(s)).

1. Your code has a severe bug. Consider: Your function succeeds, only reader.close() throws an exception. Then

finally {
..try {
….reader.close();
..} catch(IOException e) {
….log.info(“closing reader failed.”, e);
..}
}

simply swallows the exception from reader.close(). This is tolerable for a Reader but certainly not in general e.g. for a Writer and other ‘resources’.

2. It is very hard to maintain the original exception when another exception occurs during stack unwinding.

3. ‘Hidden’ exceptions are a mere theoretical problem. They are hardly ever seen in real world applications and it makes no sense to add extra code to handle them.

In the finally block, the reader should be checked for not null.