Is there any condition where finally might not run in java? Thanks.
+17
A:
System.exit shuts down the Virtual Machine.
Terminates the currently running Java Virtual Machine. The argument serves as a status code; by convention, a nonzero status code indicates abnormal termination.
This method calls the
exitmethod in classRuntime. This method never returns normally.
try {
System.out.println("hello");
System.exit(0);
}
finally {
System.out.println("bye");
} // try-finally
"bye" does not print out in above code.
eed3si9n
2009-01-21 04:41:14
+37
A:
from the Sun Tutorials
Note: If the JVM exits while the try or catch code is being executed, then the finally block will not execute. Likewise, if the thread executing the try or catch code is interrupted or killed, the finally block will not execute even though the application as a whole continues.
I don't know of any other ways the finally block wouldn't execute...
hhafez
2009-01-21 04:42:56
@dhiller - I'm pretty sure that "power down" is included in "If the JVM exits..." :-p
Jason Coco
2009-01-21 07:24:25
@Jason Coco: Terminating (as upon loss of power) is not quite the same thing as exiting; the latter is a more or less organized process culminating in the former. ;p
2010-10-13 06:42:49
+8
A:
Just to expand on what others have said, anything that does not cause something like the JVM exiting will incur the finally block. So the following method:
public static int Stupid() {
try {
return 0;
}
finally {
return 1;
}
}
will strangely both compile and return 1.
Daniel Nadasi
2009-01-21 05:53:28
It's considered a bad idea to return a value from a finally block. Either return only from the try block, or return from outside the try/finally block. Most IDEs will mark this with a warning.
Ran Biron
2009-01-21 05:59:54
+4
A:
Related to System.exit, there are also certain types of catastrophic failure where a finally block may not execute. If the JVM runs out of memory entirely, it may just exit without catch or finally happening.
Specifically, I remember a project where we foolishly tried to use
catch (OutOfMemoryError oome) {
// do stuff
}
This didn't work because the JVM had no memory left for executing the catch block.
Zarkonnen
2009-01-21 09:57:22
When OutOfMemoryError is thrown there is usually lots of memory left (to stop GC thrashing). However, if you catch it repeatedly you obviously will get back to GC thrashing.
Tom Hawtin - tackline
2009-01-21 13:44:00
+2
A:
try { for (;;); } finally { System.err.println("?"); }
In that case the finally will not execute (unless the deprecated Thread.stop is called, or an equivalent, say, through a tools interface).
Tom Hawtin - tackline
2009-01-21 13:47:40
This page claims that a ThreadDeath error is thrown, and that the stack unwinds normally when Thread.stop() is called. Is there a catch that I am missing? http://download.oracle.com/docs/cd/E17476_01/javase/1.5.0/docs/guide/misc/threadPrimitiveDeprecation.html
spurserh
2010-07-18 14:40:44
I don't think there's a catch. Perhaps there you are imagining a catch that isn't there. If we put in an explicit `throw`, then the `finally` block will execute as expected. `try { throw new ThreadDeath(); } finally { System.err.println("?"); }`
Tom Hawtin - tackline
2010-07-19 11:46:34
+1
A:
Sun tutorial has been wrongly quoted here in this thread
Note: If the JVM exits while the try or catch code is being executed, then the finally block will not execute. Likewise, if the thread executing the try or catch code is interrupted or killed, the finally block will not execute even though the application as a whole continues.
If you look into sun tutorial closely for finally block, it doesn't say "will not execute" but "may not execute" Here is the correct description
Note: If the JVM exits while the try or catch code is being executed, then the finally block **may** not execute. Likewise, if the thread executing the try or catch code is interrupted or killed, the finally block **may** not execute even though the application as a whole continues.
The apparent reason for this behavior is, call to system.exit() is processed in a runtime system thread which may take time to shutdown the jvm, meanwhile thread scheduler can ask finally to execute. So finally is designed to always execute, but if you are shutting down jvm, it may happen that jvm shuts down prior to finally getting being executed.
saurabh
2010-04-30 12:45:59