is an exception inside a finally block going to be logged in stack trace

[Bangar Raju]

Hi,

An exception in finally block is going to be logged in stack trace or it will redirect to the calling methods catch block with out logging the line where the exception occurred.

we are not able to trace where exactly the exception occurred, so we are suspecting that the exception occurred in finally block.

Thanks in Advance...

Regards,

Bangar Raju

[Ilja Preuss]

An exception that is thrown in a finally block will show the correct source line just as normal.

Can you post the stacktrace and the code that is responsible for the exception?

[Jim Yingst]

Bangar, do you have a stack trace at all? As Ilja said, the stack trace should work for a finally block, same as for other exceptions. Unless it's being caught by code that doesn't log the stack trace at all. Or unless it's an exception that does not have a good stack trace - this happens sometimes for some problems where the system is unable to keep track of all the things going on, like a StackOverflowError or OutOfMemoryException. Sometimes. But you should at least be able to discover the name of the exception, which will give a clue as to the nature of the problem.

Also, if an exception is thrown in a finally block, this may conceal another exception that was thrown before the finally block. This should not in any way prevent you from getting a log that shows where the second exception was thrown in the finally block. But if and when you find an exception that originated in a finally block, you should consider the possibility that there was another exception earlier, and you've now lost that info. For this reason it's often a good idea to avoid anything in a finally block that can cause an exception of its own - or to use an extra try/catch inside the finally (maybe refactored into a separate method) to ensure that the new exception gets logged but does not interfere with any previous exception

For example:

InputStream in = new FileInputStream("myfile.txt");
try {
    // read file
} finally {
    in.close();
}

If an exception is thrown from in.close(), it could mask an earlier exception from the //read file section. Instead you might do this:

InputStream in = new FileInputStream("myfile.txt");
try {
    // read file
} finally {
    try { in.close(); }
    catch (IOException e) { log.error("Error closing file", e); }
}

or

InputStream in = new FileInputStream("myfile.txt");
try {
    // read file
} finally {
    closeSafely(in);
}
 
...
 
private static void closeQuietly(Closeable cl) {
    try { cl.close(); }
    catch (IOException e) { log.error("Error closing Closeable", e); }
}