Page History

Code inside Methods invoked from within a finally block can throw an exception. Programmers often fail Failure to catch and handle such exceptions . This can be problematic for several reasons. An exception thrown in a finally block becomes the reason for results in the abrupt termination of the entire try block, potentially masking an . Abrupt termination causes any exception thrown in the try block . Furtherto be lost, preventing any possible recovery method from handling that specific problem. Additionally, the transfer of control associated with the exception prevents may prevent execution of any clean-up expressions or statements that follow the statement occur after the point in the finally block from which the exception is thrown. Consequently, programs must appropriately handle checked exceptions that are thrown from within a finally block.

Allowing checked exceptions to escape a finally block also violates ERR04-J. Do not complete abruptly from a finally block.

Noncompliant Code Example

This noncompliant code example uses contains a finally block that closes the reader object. The programmer incorrectly assumes that the statements in the finally block cannot throw exceptions , and consequently fails to appropriately handle the any exception appropriatelythat may arise.

public class Operation {
  privatepublic static void doOperation(String some_file) throws IOException {
    // ... Code to check or set character encoding ...
    try {
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));
      try {
        // Do operations 
     
    } finally {
        reader.close();
        // ... Other clean-upcleanup code ...
    }
  }

   public static} voidcatch main(String[]IOException argsx) throws{
 IOException {
    String// pathForward = "somepath";to handler
    doOperation(path);}
  }
}

The close() method could can throw an IOException, which, if thrown, would prevent execution of any subsequent clean-up cleanup statements. This possibility remains undiagnosed at compile time because the close() method's throws clause specifies the same exceptions as do the throws clauses of methods read() and write()problem will not be diagnosed by the compiler because any IOException would be caught by the outer catch block. Also, an exception thrown from the close() operation can mask any exception that gets thrown during execution of the Do operations block, preventing proper recovery.

Compliant Solution (Handle Exceptions in finally Block)

This compliant solution correctly places encloses the close() statement method invocation in a try-catch block of its own within the finally block. Consequently, an the potential IOException can be handled without permitting allowing it to propagate fartherfurther.

public class Operation {
  public static void doOperation(String some_file) throws IOException {
    // ... Code to check or set character encoding ...
    try {
      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-upcleanup code ...
    }
  }

   public static} voidcatch main(String[]IOException argsx) throws{
 IOException {
    String// pathForward = "somepath";to handler
    doOperation(path);}
  }
}

Compliant Solution (

...

try-with-resources)

Java SE 7 introduced a feature called try-with-resources that can close certain resources automatically in the event of an error. This compliant solution uses try-with-resources to properly close the fileWhen closing a stream without throwing an exception is a frequent pattern in the code, an alternative solution is to use a closeHandlingException() method, as shown in this compliant solution.

public class Operation {
  public static void doOperation(String some_file) throws IOException { {
    // ... Code to check or set character encoding ...
    try ( // try-with-resources
      BufferedReader reader =
          new BufferedReader(new FileReader(some_file));

    try) {
      // Do operations
    } finallycatch (IOException ex) {
      closeHandlingException(readerSystem.err.println("thrown exception: " + ex.toString());
      // Other clean-up code Throwable[] suppressed = ex.getSuppressed();
    }
  } 

  private static void closeHandlingException(BufferredReader sfor (int i = 0; i < suppressed.length; i++) {
    if (s != null) {    System.err.println("suppressed exception: " 
      try {
       + s.closesuppressed[i].toString());
      } catch (IOException ie) {
        // IgnoreForward exception if close fails
      }to handler
    }
  }

  public static void main(String[] args) throws IOException {
    if (args.length < 1) {
    doOperation("somepath"  System.out.println("Please supply a path as an argument");
      return;
    }
    doOperation(args[0]);
  }
}

When an IOException occurs in the try block of the doOperation() method, it is caught by the catch block and printed as the thrown exception. Exceptions that occur while creating the BufferedReader are included. When an IOException occurs while closing the reader, that exception is also caught by the catch block and printed as the thrown exception. If both the try block and closing the reader throw an IOException, the catch clause catches both exceptions and prints the try block exception as the thrown exception. The close exception is suppressed and printed as the suppressed exception. In all cases, the reader is safely closed.

Risk Assessment

Failure to handle an exception in a finally block can lead to may have unexpected results.

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this guideline on the CERT website.

Bibliography

\[[Bloch 2005|AA. Bibliography#Bloch 05]\] Puzzle 41: Field and Stream
\[[Harold 1999|AA. Bibliography#Harold 99]\]
\[[Chess 2007|AA. Bibliography#Chess 07]\] 8.3 Preventing Resource Leaks (Java)

Automated Detection

Related Guidelines

Bibliography

...

Image Added Image Added Image AddedERR04-J. Do not exit abruptly from a finally block      06. Exceptional Behavior (EXC)      EXC06-J. Do not allow exceptions to expose sensitive information