In the presence of Never use return
, break
, continue
, or throw
statements within a finally
block. When program execution enters a try
block that has a finally
block, irrespective the finally
block always executes regardless of whether the try
block (or any associated catch
blocks execute ) executes to completion or not, normal completion. Statements that cause the finally
block is executed. Consequently, statements that to complete abruptly also cause the finally
try
block to terminate abruptly may mask any thrown exceptions. Keywords such as return
, break
, continue
and throw
should never be used within a finally
blockcomplete 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
try
block completes abruptly for any other reasonR
, then thefinally
block is executed. Then there is a choice:
- If the
finally
block completes normally, then thetry
statement completes abruptly for reasonR
.- If the
finally
block completes abruptly for reasonS
, then thetry
statement completes abruptly for reasonS
(and reasonR
is discarded).
Noncompliant Code Example
In this noncompliant code example, the finally
block completes abruptly because of a return
statement occurs within its body. in the block:
Code Block | ||
---|---|---|
| ||
class TryFinally { private static boolean doLogic() { try { throw new IllegalStateException(); } finally { System.out.println("Uncaughtlogic Exceptiondone"); return true; } } public static void main(String[] args) { doLogic(); } } |
Consequently, when the IllegalStateException
is thrown, it does not propagate all the way up through the call stack. This is because of the abrupt termination of the finally
block that suppresses any useful exception information from being displayed as a result of overriding the exception thrown in the try
block.
Note that this example would not be insecure if only the try
block were to return some value; the finally
block always executesThe 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. Any return
statements must occur after this block. :
Code Block | ||
---|---|---|
| ||
class TryFinally { private static boolean doLogic() { try { throw new IllegalStateException(); } finally { System.out.println("Caughtlogic Exceptiondone"); } // Any return statements must go here; // applicable only when exception is thrown conditionally } } |
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:
Code Block | ||
---|---|---|
| ||
class TryFinally { public static void main(String[] argsprivate static boolean doLogic() { try { throw new IllegalStateException(); } finally { int c; try { while ((c = input.read()) != -1) { doLogic(); } } |
If this is adopted, the compiler throws an error as the return
statement is unreachable because of the explicit, unavoidable throwing of IllegalStateException
. If the exception is thrown conditionally, the return
statement can be used without any compilation errors.
Risk Assessment
Exiting abruptly from a finally
block may result in the masking of thrown exceptions.
if (c > 128) {
break;
}
}
} catch (IOException x) {
// Forward to handler
}
System.out.println("logic done");
}
// Any return statements must go here; applicable only when exception is thrown conditionally
}
}
|
Risk Assessment
Abrupt completion of a finally
block masks any exceptions thrown inside the associated try
and catch
blocks.
Rule |
---|
Severity | Likelihood | Remediation Cost | Priority | Level |
---|
ERR04-J |
Low |
Probable |
Medium | P4 | L3 |
Automated Detection
...
TODO
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this guideline on the CERT website.
Bibliography
Wiki Markup |
---|
\[[JLS 2005|AA. Bibliography#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 2005|AA. Bibliography#Bloch 05]\] Puzzle 36: Indecision
\[[Chess 2007|AA. Bibliography#Chess 07]\] 8.2 Managing Exceptions, "The Vanishing Exception"
\[[MITRE 2009|AA. Bibliography#MITRE 09]\] [CWE ID 705|http://cwe.mitre.org/data/definitions/705.html] "Incorrect Control Flow Scoping", [CWE ID 584|http://cwe.mitre.org/data/definitions/584.html] "Return Inside Finally Block" |
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
Coverity | 7.5 | PW.ABNORMAL_TERMINATION_ OF_FINALLY_BLOCK | Implemented | ||||||
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] |
...
EXC03-J. Use a logging API to log critical security exceptions 06. Exceptional Behavior (EXC) EXC05-J. Handle checked exceptions that can be thrown within a finally block