The try...catch...finally
statement combines exception handling with clean-up code. The finally
block contains code that will be executed in all circumstances. This makes them suitable for resource management, and other kinds of cleanup.
Here is an example of the simpler (try...finally
) form:
try {
doSomething();
} finally {
cleanUp();
}
The behavior of the try...finally
is as follows:
try
block is executed.try
block:
finally
block is executed.finally
block throws an exception, that exception is propagated.try...finally
.finally
block is executed.finally
block throws an exception, that exception is propagated.The code within finally
block will always be executed. (The only exceptions are if System.exit(int)
is called, or if the JVM panics.) Thus a finally
block is the correct place code that always needs to be executed; e.g. closing files and other resources or releasing locks.
Our second example shows how catch
and finally
can be used together. It also illustrates that cleaning up resources is not straightforward.
// This code snippet writes the first line of a file to a string
String result = null;
Reader reader = null;
try {
reader = new BufferedReader(new FileReader(fileName));
result = reader.readLine();
} catch (IOException ex) {
Logger.getLogger.warn("Unexpected IO error", ex); // logging the exception
} finally {
if (reader != null) {
try {
reader.close();
} catch (IOException ex) {
// ignore / discard this exception
}
}
}
The complete set of (hypothetical) behaviors of try...catch...finally
in this example are too complicated to describe here. The simple version is that the code in the finally
block will always be executed.
Looking at this from the perspective of resource management:
reader
variable) before the try
block so that it will be in scope for the finally
block.new FileReader(...)
, the catch
is able to handle any IOError
exception from thrown when opening the file.reader.close()
in the finally
block because there are some exception paths that we cannot intercept either in the try
block or in catch
block.reader
was initialized, we also need an explicit null
test.reader.close()
call might (hypothetically) throw an exception. We don't care about that, but if we don't catch the exception at source, we would need to deal with it further up the call stack.Java 7 and later provide an alternative try-with-resources syntax which significantly simplifies resource clean-up.