Originally posted by Peter Chase:
No, I meant a RuntimeException or Error occurring during processing of the "finally". In that case, the compiler cannot help you, because any method call might throw a RuntimeException or Error.
As far as I know, a RuntimeException or Error occurring during processing of the "finally" will abort the "finally", forget any exception that was thrown in the "try" and pass the new exception/error to the caller. Nasty.
Of course, all Errors and most RuntimeExceptions are serious problems that ought not to be happening, except in the presence of bugs or serious configuration problems. So this issue doesn't cause problems often, in practice.
Yes, you're screwed.
If a Throwable is thrown (or you explicitly return) from a finally block, your code is defective. If this holds, then there is a contradiction here (reductio ad absurdum): Sun (and therefore, the Java community) states that any piece of code may throw an exception - which is why we have "unchecked exceptions" for "developer errors", therefore, since throwing an exception within a finally block is defective, a "finally block" and "a piece of code" must not co-exist. As a result, the only legitimate finally block is this:
finally{} which is absurd, therefore, the only finally block is no finally block.
Conclusion: If it holds that throwing or returning from a finally is defective and it also holds that "unchecked exceptions are for unforeseen developer errors", then there is no such thing as a legitimate finally block. I propose that "unchecked exceptions are for unforeseen developer errors" does not hold.