Code inside a finally
block can throw an exception. Programmers often fail to catch and handle such exceptions. This can be problematic for several reasons. An exception can occur in the finally
block despite compile-time checking. This can prevent other exception thrown in a finally
block becomes the reason for abrupt termination of the entire try block, potentially masking an exception thrown in the try block. Further, the transfer of control associated with the exception prevents execution of any clean-up statements from being executedthat follow the statement from which the exception is thrown. Consequently, programs must appropriately handle checked exceptions thrown from within a finally
block.
Noncompliant Code Example
This noncompliant code example uses a finally
block that closes the reader
object. However, it is incorrectly assumed The programmer incorrectly assumes that the statements occurring in the finally
block cannot throw exceptions, and consequently fails to handle the exception appropriately.
Code Block | ||
---|---|---|
| ||
public class Operation { private static void doOperation(String some_file) throws IOException { BufferedReader reader = new BufferedReader(new FileReader(some_file)); // Do operations } finally { reader.close(); // ... Other clean-up code ... } } public static void main(String[] args) throws IOException { String path = "somepath"; doOperation(path); } } |
Notably, the The close()
method can could throw an IOException
, which prevents would prevent execution of any subsequent clean-up statements from being executed. This is not detected possibility remains undiagnosed at compile time because the type of exception that close()
method's throws is clause specifies the same exceptions as do the type throws clauses of exceptions that methods read()
and write()
throw.
Compliant Solution (
...
Handle Exceptions in finally
Block)
This compliant solution correctly places the close()
statement in a try-catch
block . As a resultof its own. Consequently, an IOException
can be handled without letting permitting it to propagate any furtherfarther.
Code Block | ||
---|---|---|
| ||
public class Operation { static void doOperation(String some_file) throws IOException { BufferedReader reader = new BufferedReader(new FileReader(some_file)); try { // Do operations } finally { try { // Enclose in try-catch block reader.close(); } catch (IOException ie) { // Forward to handler } // Other clean-up code } } public static void main(String[] args) throws IOException { String path = "somepath"; doOperation(path); } } |
Compliant Solution (2) (Dedicated Method to Handle Exceptions)
If there is a frequent need to close a When closing a stream without throwing an exception is a frequent pattern in the code, an alternative solution to wrapping every call to close()
in its own try-catch
block is to use a closeIgnoringExceptioncloseHandlingException()
method, as shown in this compliant solution.
Code Block | ||
---|---|---|
| ||
public class Operation { static void doOperation(String some_file) throws IOException { BufferedReader reader = new BufferedReader(new FileReader(some_file)); try { // Do operations } finally { closeIgnoringExceptioncloseHandlingException(reader); // Other clean-up code } } private static void closeIgnoringExceptioncloseHandlingException(BufferredReader s) { if (s != null) { try { s.close(); } catch (IOException ie) { // Ignore exception if close fails } } } public static void main(String[] args) throws IOException { doOperation("somepath"); } } |
Risk Assessment
Failing Failure to handle an exception in a finally
block can lead to unexpected results.
Guideline | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
EXC05-J | low | unlikely | medium | P2 | L3 |
Automated Detection
...
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this guideline on the CERT website.
...