If a finally clause is specified, irrespective Never use return, break, continue, or throw statements within a finally block. When program execution enters a try block that has a finally block, the finally block always executes regardless of whether the try block (or any associated catch block blocks) executes to completion or not, the finally block is executed. Conseuqnetly statements that abruptly exit from the finally block may cause related catch blocks to not be executed. Thus, keywords like return, break, continue and throw should never be used within a finally block.
Noncompliant Code Example
Here, the finally block completes abruptly since a return statement occurs within it. As a result, when the exception is thrown in method someException, it does not show up in the output. This is due to the abrupt termination of the finally block that suppresses any useful exception information displayed in the try block by overriding it with its own message. Note that even if the try block returns some value, the finally block is executed.
normal completion. Statements that cause the finally block to complete abruptly also cause the try block to complete abruptly and consequently suppress any exception thrown from the try or catch blocks. According to The Java Language Specification, §14.20.2, "Execution of try-finally and try-catch-finally" [JLS 2015]:
If execution of the
tryblock completes abruptly for any other reasonR, then thefinallyblock is executed. Then there is a choice:
- If the
finallyblock completes normally, then thetrystatement completes abruptly for reasonR.- If the
finallyblock completes abruptly for reasonS, then thetrystatement completes abruptly for reasonS(and reasonRis discarded).
Noncompliant Code Example
In this noncompliant code example, the finally block completes abruptly because of a return statement in the block:Note that MullPointerException is a RuntimeException, and thus does not need to occur in a throws declaration. The throwException() function never actually throws a SomeException class, although it claims to via its throws declaration.
| Code Block | ||
|---|---|---|
| ||
class SomeExceptionTryFinally extends{ Exception {private static boolean public SomeException(String sdoLogic() { super(s);try { } } class TryFinally { privatethrow staticnew void throwExceptionIllegalStateException() throws SomeException; } finally { throw new NullPointerException(System.out.println("logic done"); } return true; } } } |
The IllegalStateException is suppressed by the abrupt completion of the finally block caused by the return statement.
Compliant Solution
This compliant solution removes the return statement from the finally block:
| Code Block | ||
|---|---|---|
| ||
class TryFinally { private static private boolean doLogic() { try { throw new throwExceptionIllegalStateException(); } catch (SomeException se) { System.out.println("Exception thrown"); } finally { System.out.println("Uncaughtlogic Exceptiondone"); } // Any return statements must go return truehere; } } public// staticapplicable void main(String[] args) { doLogic(); only when exception is thrown conditionally } } |
Compliant Solution
Exceptions
ERRO4-J-EX0: Control flow statements whose destination is within the finally block are perfectly acceptable. For example, the following code does not violate this rule because the break statement exits within the while loop but not within the finally block:This compliant solution removes the return statement from the finally block.
| Code Block | ||
|---|---|---|
| ||
class SomeException extends Exception { class TryFinally { private static boolean doLogic() { public SomeException(String s)try { superthrow new IllegalStateException(s); } } class TryFinally finally { int c; try { private static void throwException() throws SomeException while ((c = input.read()) != -1) { throw new NullPointerException(); } if (c > 128) { break; static private void doLogic() { try {} } throwException(); } catch (SomeExceptionIOException sex) { System.out.println("Exception thrown"); } finally { // Forward to handler } System.out.println("Uncaughtlogic Exceptiondone"); } return true; } public static void main(String[] args) { doLogic(); // Any return statements must go here; applicable only when exception is thrown conditionally } } |
Risk Assessment
Exiting abruptly from Abrupt completion of a finally block may have unexpected resultsmasks any exceptions thrown inside the associated try and catch blocks.
Rule | Severity | Likelihood |
|---|
Detectable | Repairable | Priority | Level |
|---|
ERR04-J |
Low | Probable |
Yes |
Yes |
P6 |
L2 |
Automated Detection
...
TODO
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
| Wiki Markup |
|---|
\[[JLS 05|AA. Java References#JLS 05]\] [Section 14.20.2, Execution of try-catch-finally|http://java.sun.com/docs/books/jls/third_edition/html/statements.html#14.20.2]
\[[Bloch 05|AA. Java References#Bloch 05]\] Puzzle 36: Indecision |
Tool | Version | Checker | Description | ||||||
|---|---|---|---|---|---|---|---|---|---|
| Coverity | 7.5 | PW.ABNORMAL_TERMINATION_ OF_FINALLY_BLOCK | Implemented | ||||||
| Klocwork |
| JD.FINRET | |||||||
| Parasoft Jtest |
| CERT.ERR04.ARCF CERT.ERR04.ATSF | Avoid using 'return's inside 'finally blocks if thare are other 'return's inside the try-catch block Do not exit "finally" blocks abruptly | ||||||
| PVS-Studio |
| V6051 | |||||||
| SonarQube |
| S1143 | Jump statements should not occur in "finally" blocks |
Related Guidelines
Bibliography
Puzzle 36. Indecision | |
Section 8.2, "Managing Exceptions, The Vanishing Exception" | |
[JLS 2015] |
...
EXC04-J. Prevent against inadvertent calls to System.exit() or forced shutdown 10. Exceptional Behavior (EXC) EXC31-J. Handle checked exceptions that can be thrown within a finally block