Oh wait-- I said this test passed on both boxpilers, but I didn’t realize the try catch was hiding the error and I didn’t notice it in the debug tab of VSCode. So this IS erroring, but only on the ASM Boxpiler! Looking at the transformer for BoxReturn, the logic is different than what I had in the Java BoxPiler version so I’m not sure what’s going on there. The code seems to be finding that it’s inside of a function and ignores the fact that it’s also inside of a cflock first. I would recommend reviewing that logic in the BoxReturnTransformer and making it match the logic in the Java transformer.

I have left the test testBodyResultError is CoreLangTests disabled. You can re-enable it to fix this ticket.

Did you fix that other body result issue and if so, what build of BL were those fixes in? This would boil down to the generated bytecode for the return construct returning null instead of a bodyResult instance. I’m wondering if perhaps it was fixed on a later version.

Lol, the boxpiler can be set in your boxlang.json file inside the BL home, or via an env var. I added your code snippet above to a .cfc in our test suite and added a test that runs this code:

but it runs without error on both the Java and ASM BoxPiler. I’m not sure how to reproduce this.

Here is the stack trace I get. Regarding the compilation model being used, I don’t know enough about the engine to know if this is being compiled or interpreted or boxpiled or boxterpreted or etc.

Can you test if this same error happens with the Java BoxPiler? The stack trace would be great too.