Try/catch/finally builder

[Paul Sandoz]

“Whew!” indeed. It gets even more complex if a finally block does silly stuff like exit with a return or break to an outer try statement (I forgot about that, so not currently supported). The testing matrix is already exploding in my head :-)

Not easy to get right if the user has to explicitly inline, and not possible as you point out if code generation is layered via some other intermediaries.

Yes, return instructions are implicitly supported since we know that exits the block:

boolean isBlockExitingInstruction(CodeElement e) {
    return switch (e) {
        case BranchInstruction bi -> inlineFinally.test(this, bi);
        case ReturnInstruction ri -> true;
        default -> false;
    };
}

Setting that aside, the real question is whether a branch target that is a branch target is internal to the try+catch blocks, or "outside”.

Yes, that is what I am grappling with.


 Which we would handle by examining the label.  But the usability of this is not so great, because the label may not have been bound yet, and so all the user can do is compare it for identity with the N labels known to be in the block.  That sounds like kind of a pain for the user to implement.


Indeed.


So here's another possible thought: what if BlockBuilder could dispense labels, as well as dispensing blocks, and could then keep track of containment?  So if you are branching to a label *outside this block builder* (including returning), we'd inline the finally at that point.  (With nested block builders, we'd have to keep track of which BBs belonged to other BBs, but we already do this.)

That’s a good idea. We can accumulate the set of labels produced by calls to newLabel, then compare branch targets against that set.

Somehow we should “disable” unbound labels when the block ends. We could just bind them all to the end, then they cannot be rebound in unwanted places.

Seems ok for a block label to be bound in a nested block builder.

Paul.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20220826/2ddaf885/attachment-0001.htm>