Probably because of this (the date of the commit is the same as the date of the messages): https://groups.google.com/g/clojure/c/Y6fHOCjmcxk/m/YuIGPMpHMRAJ

Hm, nice digging. I'd also figure that's related.

It still doesn't quite explain what the problem would be. I'm suspecting it's JVM-specific, but I'll need to look into what a VerificationError is.

But no clue what VerificationError means, can't find it.

Maybe it's actually java.lang.VerifyError.

Good catch. This has some interesting info. https://stackoverflow.com/questions/100107/causes-of-getting-a-java-lang-verifyerror

> You would get this error if the bytecode size of your method exceeds the 64kb limit; but you would probably have noticed that.

Could be related.

Either way, definitely something JVM-specific. I'll try without it in jank and see what we run into. I appreciate the help!

Oh, that's fun! I got pre-1.0.0 Clojure up and running to reproduce it:

Clojure
user=> (def k)
#'user/k
user=> (. k dosomething (do (try :something (catch java.lang.Exception
e :something-else)) nil))
java.lang.VerifyError: (class: user/eval__3741, method: invoke signature: ()Ljava/lang/Object;) Inconsistent stack height 0 != 5
java.lang.VerifyError: (class: user/eval__3741, method: invoke signature: ()Ljava/lang/Object;) Inconsistent stack height 0 != 5
        at java.lang.Class.getDeclaredConstructors0(Native Method)
        at java.lang.Class.privateGetDeclaredConstructors(Class.java:2398)
        at java.lang.Class.getConstructor0(Class.java:2708)
        at java.lang.Class.newInstance0(Class.java:328)
        at java.lang.Class.newInstance(Class.java:310)
        at clojure.lang.Compiler$FnExpr.eval(Compiler.java:2984)
        at clojure.lang.Compiler.eval(Compiler.java:3843)
        at clojure.lang.Repl.main(Repl.java:75)

Huh. What does that error even mean?

The bytecode that try/catch compiled to doesn't really have expression semantics, the easiest way to make it an expression is to lift it into a method, and the easiest way to lift it into a method is to wrap it in a fn

I can get that. Early jank codegen (to C++) wrapped everything in lambdas for expression semantics as well. I suppose this is a limitation at the JVM bytecode level.

The compiler does it for a number of different forms try/catch loop and if

Yeah, the bytecode verifier imposes stricter requirements

(although funnily if I recall case doesn't get wrapped)

Gotcha. Thanks for the additional context. I'm happy to see the few cases where jank gets to be simpler than Clojure, since the vast majority of the cases the JVM is helping, not getting in the way. 😄

https://clojure.atlassian.net/browse/CLJ-701 an annoying thing is the wrapping loses type hints

Ahh, yes.

I talked to Rich about this once, and I think he mentioned that it was challenging to nest all the exception handlers in the bytecode

exception tables need bytecode ranges

If I wanted to educate myself on things like that (JVM implementation details, not necessarily how they're affecting Clojure), what would be good resources for that? I assume the spec, but maybe something else?