> The projects examined contained a total of 120,964,221 lines of Python code, and among them the script found 203 instances of control flow instructions in a finally block. Most were return, a handful were break, and none were continue.
I don't really write a lot of Python, but I do write a lot of Java, and `continue` is the main control flow statement that makes sense to me within a finally block.
I think it makes sense when implementing a generic transaction loop, something along the lines of:
<T> T executeTransaction(Function<Transaction, T> fn) {
for (int tries = 0;; tries++) {
var tx = newTransaction();
try {
return fn.apply(tx);
} finally {
if (!tx.commit()) {
// TODO: potentially log number of tries, maybe include a backoff, maybe fail after a certain number
continue;
}
}
}
}
In these cases "swallowing" the exception is often intentional, since the exception could be due to some logic failing as a result of inconsistent reads, so the transaction should be retried.
The alternative ways of writing this seem more awkward to me. Either you need to store the result (returned value or thrown exception) in one or two variables, or you need to duplicate the condition and the `continue;` behaviour. Having the retry logic within the `finally` block seems like the best way of denoting the intention to me, since the intention is to swallow the result, whether that was a return or a throw.
If there are particular exceptions that should not be retried, these would need to be caught/rethrown and a boolean set to disable the condition in the `finally` block, though to me this still seems easier to reason about than the alternatives.
The finally behave slightly different in CIL. You have protected regions and finally/fault/catch/filters handlers attached. So in order to support continue inside finally you should introduce some state machine , which is complication and generally against Roslyn design limitation.
That's not just Java and there is nothing really cursed about it: throwing in a finally block is the most common example. Jump statements are no different, you can't just ignore them when they override the return or throw statements.
try/finally is effectively try/catch(Throwable) with copy all the code of the finally block prior to exiting the method. (Java doesn't have a direct bytecode support for 'finally')
this broke my head. I think I haven't touched Java in a while and kept thinking continue should be in a case/switch so ittook a minute to back out of that alleyway before I even got what was wrong with this.
If by coroutines the author meant virtual threads, then monitors have always been compatible with virtual threads (which have always needed to adhere to the Thread specification). Monitors could, for a short while, degrade the scalability of virtual threads (and in some situations even lead to deadlocks), but that has since been resolved in JDK 24 (https://openjdk.org/jeps/491).
I think it's coroutines as in other JVM languages like Kotlin, where yielding may be implemented internally as return (due to lack of native coroutine support in JVM).
Holding a lock/monitor across a yield is a bad idea for other reasons, so it shouldn't be a big deal in practice.
I meant polyfilled coroutines used by other JVM languages, like Kotlin. When you compile a coroutine to a state machine, yielding has to return from the machine; but JVM does not support unbalanced monitors, although it obviously does support unbalanced locking operations with normal mutexes.
Older versions of Java did try to have only one copy of the finally block code. To implement this, there were "jsr" and "ret" instructions, which allowed a method (a subroutine) to contain subroutines inside it. This even curseder implementation of finally is prohibited starting from version 51 class files (Java 7).
Doesn't JRE has some limited form of decompilation in its JIT, as a pre-pass? IIRC, it reconstructs the basic blocks and CFG from the bytecode and does some minor optimizations before going on to regalloc and codegen.
On the subject
is my favorite cursed Java exceptions construct.
To anyone wondering, I believe it's cursed because the finally continue blocks hijacks the try return, so the for loop never returns
So the function returns, and then during its tidyup, the 'continue' basically comefrom()s the VM back into the loop? That is, indeed, cursed.
19 replies →
see, if you only had GOTO's, this would be obvious what is going on!
Python has the same construct but is removing it, starting with a warning in version 3.14: https://peps.python.org/pep-0765/
There was a recent talk at PYCON UK about it, by one of the authors of the PEP in question: <https://www.youtube.com/watch?v=vrVXgeD2fts>
1 reply →
Interesting .. from the post above:
> The projects examined contained a total of 120,964,221 lines of Python code, and among them the script found 203 instances of control flow instructions in a finally block. Most were return, a handful were break, and none were continue.
I don't really write a lot of Python, but I do write a lot of Java, and `continue` is the main control flow statement that makes sense to me within a finally block.
I think it makes sense when implementing a generic transaction loop, something along the lines of:
In these cases "swallowing" the exception is often intentional, since the exception could be due to some logic failing as a result of inconsistent reads, so the transaction should be retried.
The alternative ways of writing this seem more awkward to me. Either you need to store the result (returned value or thrown exception) in one or two variables, or you need to duplicate the condition and the `continue;` behaviour. Having the retry logic within the `finally` block seems like the best way of denoting the intention to me, since the intention is to swallow the result, whether that was a return or a throw.
If there are particular exceptions that should not be retried, these would need to be caught/rethrown and a boolean set to disable the condition in the `finally` block, though to me this still seems easier to reason about than the alternatives.
13 replies →
Just tested that in C# and it seems they made the smart decision to not allow shenanigans like that in a finally block:
CS0157 Control cannot leave the body of a finally clause
What about throwing an exception from the finally clause?
2 replies →
The finally behave slightly different in CIL. You have protected regions and finally/fault/catch/filters handlers attached. So in order to support continue inside finally you should introduce some state machine , which is complication and generally against Roslyn design limitation.
1 reply →
That's not just Java and there is nothing really cursed about it: throwing in a finally block is the most common example. Jump statements are no different, you can't just ignore them when they override the return or throw statements.
It is just Java as far as I can tell. Other languages with a finally don't allow for explicitly exiting the finally block.
4 replies →
> override the return
How is this not cursed
It is Java as C# disallow this
In JDK 25, you can run this code:
This is exceedingly nasty. Well Done!
try/finally is effectively try/catch(Throwable) with copy all the code of the finally block prior to exiting the method. (Java doesn't have a direct bytecode support for 'finally')
Nothing that cursed.
It compiles to this:
Won't that particular code fail to compile in java because the return is unreachable?
this broke my head. I think I haven't touched Java in a while and kept thinking continue should be in a case/switch so ittook a minute to back out of that alleyway before I even got what was wrong with this.
Isn't this just an endless loop with extra steps?
Nice post!
A minor point:
> monitors are incompatible with coroutines
If by coroutines the author meant virtual threads, then monitors have always been compatible with virtual threads (which have always needed to adhere to the Thread specification). Monitors could, for a short while, degrade the scalability of virtual threads (and in some situations even lead to deadlocks), but that has since been resolved in JDK 24 (https://openjdk.org/jeps/491).
I think it's coroutines as in other JVM languages like Kotlin, where yielding may be implemented internally as return (due to lack of native coroutine support in JVM).
Holding a lock/monitor across a yield is a bad idea for other reasons, so it shouldn't be a big deal in practice.
I meant polyfilled coroutines used by other JVM languages, like Kotlin. When you compile a coroutine to a state machine, yielding has to return from the machine; but JVM does not support unbalanced monitors, although it obviously does support unbalanced locking operations with normal mutexes.
Older versions of Java did try to have only one copy of the finally block code. To implement this, there were "jsr" and "ret" instructions, which allowed a method (a subroutine) to contain subroutines inside it. This even curseder implementation of finally is prohibited starting from version 51 class files (Java 7).
Doesn't JRE has some limited form of decompilation in its JIT, as a pre-pass? IIRC, it reconstructs the basic blocks and CFG from the bytecode and does some minor optimizations before going on to regalloc and codegen.
It's hard to call it decompilation as opposed to just regular compilation though.