<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
“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 :-)
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">Yes, return instructions are implicitly supported since we know that exits the block:</div>
<div class="">
<pre style="background-color:#ffffff;color:#080808;font-family:'JetBrains Mono',monospace;font-size:9.8pt;" class=""><span style="color:#0033b3;" class="">boolean </span><span style="color:#00627a;" class="">isBlockExitingInstruction</span>(<span style="color:#000000;" class="">CodeElement </span>e) {<br class=""> <span style="color:#0033b3;" class="">return switch </span>(e) {<br class=""> <span style="color:#0033b3;" class="">case </span><span style="color:#000000;" class="">BranchInstruction </span>bi -> <span style="color:#871094;" class="">inlineFinally</span>.test(<span style="color:#0033b3;" class="">this</span>, bi);<br class=""> <span style="color:#0033b3;" class="">case </span><span style="color:#000000;" class="">ReturnInstruction </span>ri -> <span style="color:#0033b3;" class="">true</span>;<br class=""> <span style="color:#0033b3;" class="">default </span>-> <span style="color:#0033b3;" class="">false</span>;<br class=""> };<br class="">}<br class=""></pre>
<div class="">
<blockquote type="cite" class="">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”.
</blockquote>
<div class=""><br class="">
</div>
Yes, that is what I am grappling with.</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
<blockquote type="cite" class=""> 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.<br class="">
<br class="">
</blockquote>
<div class=""><br class="">
</div>
Indeed.</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
<blockquote type="cite" class="">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.) </blockquote>
</div>
</div>
<div class=""><br class="">
</div>
<div class="">That’s a good idea. We can accumulate the set of labels produced by calls to newLabel, then compare branch targets against that set. </div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">Seems ok for a block label to be bound in a nested block builder.</div>
<div class=""><br class="">
</div>
<div class="">Paul. </div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
</body>
</html>