<div dir="ltr"><div>Hello,</div><div>I'd like to share soe further "progress" (and lack of) on this topic and some further considerations.</div><div><br></div><div>First, we managed to get this to work for a particular case through our consumer code: we can override the Gen.visitErroneous and Gen.visitExec methods to generate the bytecode of `throw new RuntimeException("Compilation error")` instead of crashing. And I could see that the generate .class throw the exception when expected. So that's very encouraging.<br></div><div>However this is unfortunately too restricted: one more generic idea is to override the `Gen.genExpr(...)` method so that is the expression is JCErroneous or type is null, then we generate the bytecode for `throw new RuntimeException("Compilation Error")`. But the issue is that one cannot really override `genExpr` because it returns an object of the package-visible only Item type, so we can simply not override it. We've tried to greedily duplicate most of the com.sun.tools.javac.jvm package but the "Code" type which is used by Symbol but still has some important nested types that are not open make that even duplicating the code in the package is diffcult.</div><div>So implementation-wise, I think we are getting close to a conclusion that fully providing such ability through consumer code is for the moment about impossible. Changes seems necessary in openjdk directly.</div><div><br></div><div>On that matter, we came to learn about `should-stop.ifError` and it seems that in case `should-stop.ifError=GENERATE` then generating the class for erroneous .java files similarly to what we suggest above is a fair expectation, isn't it? That would mean that basically, there would be no need for a new flag, nor a new option, and we'd "just" have to fix the currently crashing bits of javac?</div><div><br></div><div>If anyone has further suggestions to experiment, they are for sure welcome!</div><div><br></div><div>Cheers,</div></div>