What Happens If a Finally Block Throws an Exception

What happens if a finally block throws an exception?

If a finally block throws an exception what exactly happens ?

That exception propagates out and up, and will (can) be handled at a higher level.

Your finally block will not be completed beyond the point where the exception is thrown.

If the finally block was executing during the handling of an earlier exception then that first exception is lost.

C# 4 Language Specification § 8.9.5: If the finally block throws another exception, processing of the current exception is terminated.

Exception thrown in catch and finally clause

Based on reading your answer and seeing how you likely came up with it, I believe you think an "exception-in-progress" has "precedence". Keep in mind:

When an new exception is thrown in a catch block or finally block that will propagate out of that block, then the current exception will be aborted (and forgotten) as the new exception is propagated outward. The new exception starts unwinding up the stack just like any other exception, aborting out of the current block (the catch or finally block) and subject to any applicable catch or finally blocks along the way.

Note that applicable catch or finally blocks includes:

When a new exception is thrown in a catch block, the new exception is still subject to that catch's finally block, if any.

Now retrace the execution remembering that, whenever you hit throw, you should abort tracing the current exception and start tracing the new exception.

Does a finally block run even if you throw a new Exception?

Yes, the finally blocks always runs... except when:

• The thread running the try-catch-finally block is killed or interrupted
• You use System.exit(0);
• The underlying VM is destroyed in some other way
• The underlying hardware is unusable in some way

Additionally, if a method in your finally block throws an uncaught exception, then nothing after that will be executed (i.e. the exception will be thrown as it would in any other code). A very common case where this happens is java.sql.Connection.close().

As an aside, I am guessing that the code sample you have used is merely an example, but be careful of putting actual logic inside a finally block. The finally block is intended for resource clean-up (closing DB connections, releasing file handles etc), not for must-run logic. If it must-run do it before the try-catch block, away from something that could throw an exception, as your intention is almost certainly functionally the same.

How to handle throw exceptions inside finally block in java

Best way to handle this problem is to use try-with-resource. But if someone want to close the connection manually and show the exception of the try or catch block without hiding, following code snippet is the solution.

public void upload(File file) throws IOException {
    ChannelSftp c = (ChannelSftp) channel;
    BufferedInputStream bis = new BufferedInputStream(file.toInputStream());
    SftpException sftpException = null;
    try {
        String uploadLocation = Files.simplifyPath(this.fileLocation + "/" + file.getName());
        c.put(bis, uploadLocation);
    } catch (SftpException e) {
        sftpException = e;
        throw new IllegalTargetException("Error occurred while uploading " + e.getMessage());
    } finally {
        if (sftpException != null) {
            try {
                bis.close();
            } catch (Throwable t) {
                sftpException.addSuppressed(t);
            }
        } else {
            bis.close();
        }
    }
}

Does finally completely execute if an exception is thrown within finally block

Basically, finally clauses are there to ensure proper release of a resource. However, if an exception is thrown inside the finally block, that guarantee goes away.

An issue for which there's no really neat solution is that code in the finally block could itself throw an exception. In this case, the exception in the finally block would be thrown from the exception instead of any exception occurring inside the try block. Since code in the finally block is intended to be "cleanup" code, we could decide to treat exceptions occurring there as secondary, and to put an excplicit catch:

public int readNumber(File f) throws IOException, NumberFormatException {
  BufferedReader br = new BufferedReader(new
    InputStreamReader(new FileInputStream(f), "ASCII"));
  try {
    return Integer.parseInt(br.readLine());
  } finally {
    try { br.close(); } catch (IOException e) {
      // possibly log e
    }
  }
}

Some other things to note about finally blocks:

1. The same 'overriding' problem that we mentioned with exceptions
   occurs when returning a value from a finally block: this would
   override any return value that the code in the try block wanted to
   return. In practice, returning a value from a finally clause is rare
   and not recommended.
2. Actually exiting the program (either by calling System.exit() or by
   causing a fatal error that causes the process to abort: sometimes
   referred to informally as a "hotspot" or "Dr Watson" in Windows)
   will prevent your finally block from being executed!
3. There's nothing to stop us nesting try/catch/finally blocks (for
   example, putting a try/finally block inside a try/catch block, or
   vice versa), and it's not such an uncommon thing to do.

Why an exception thrown from finally block ignores an exception thrown from catch block?

The finally block is always executed, regardless of whether the try block throws an exception or not (and regardless of whether it has a return statement or not).

Therefore, the exception thrown by the finally block - IOException - is the only exception thrown by your method, and it's always thrown, regardless of the content of the try block. Therefore your method only has to declare that it throws IOException.

What happens if both catch and finally blocks throw exception?

When the finally block throws an exception, it will effectively hide the exception thrown from the catch block and will be the one ultimately thrown. It is therefore important to either log exceptions when caught, or make sure that the finally block does not itself throw an exception, otherwise you can get exceptions being thrown that are stifled and never seen.

---

Related Topics