That's really weird

perhaps it has something to do with inlining?

That would be my guess too, but I've no idea how inlining actually works to test it

Can imagine it’s something like that

((fn [x] (/ 1.0 x)) 0.0) ;=> ##Inf

((fn [x] (divide 1.0 x)) 0.0) ;=> ArithmeticException Divide by zero
((partial / 1.0) 0.0) ;=> ArithmeticException Divide by zero
((comp /) 1.0 0.0) ;=> ArithmeticException Divide by zero
((identity /) 1.0 0.0) ;=> ArithmeticException Divide by zero

(eval '(/ 1.0 0.0)) ;=> ##Inf

=> (ns clojure.core)
nil
=> ((nary-inline 'divide) 1.0 0.0)
(. clojure.lang.Numbers (divide 1.0 0.0))
=> (. clojure.lang.Numbers (divide 1.0 0.0))
##Inf

That's how the inlining works, but doesn't explain why it's failing on the second case

The inlined version divides double primitives. The not inlined version divides Double objects.

The primitive version just does x / y in Java, which results in ##Inf. The Double version does an explicit check.

Neat

A funny thing:

(def x 1.0)
=> #'user/x
(def y 0.0)
=> #'user/y
(/ 1.0 y)
=> ##Inf
(/ x y)
Execution error (ArithmeticException) at user/eval5664 (form-init10727573377274659587.clj:1).
Divide by zero

static public double divide(double x, Object y){
	return x / ((Number)y).doubleValue();  // <- returns a primitive as well
}

Make sure that the Java version that Lein uses is indeed 17 and not, say, 8.

You can check it by running lein --version.

I ran "lein --version": Leiningen 2.9.8 on Java 17.0.2 Java HotSpot(TM) 64-Bit Server VM

Hm, weird. But still - Java not recognizing var is a symptom of an old version being used, AFAICT. Maybe lein has some additional Java selection mechanisms inside it.

Note how the error mentions lein javac. Maybe you have javac on the PATH from an old JDK, somehow.

I fixed it. It somehow was depending on an old version of Java even though it showed Java17.0.2

Only deleting the old version made it work

@U4J1HQKFH? 🙂

lol - it was too short for my filter

sadly, I don't think he checks very often, as I messaged him a couple months ago and he never responded.

I'll open up a github issue to ask him on to the podcast in that case ;-)

Of course, you don't have to rename - you can just exclude core’s functions if you like

But I read the function as more coercion than parsing

So coerce-long, to-long, ->long seem like options

we would have to exclude them in every namespace they're used, right? I'm trying to avoid that kind of busywork

those names are great, thanks

ensure-long

The only thing to be careful with if you rename all your company-specific ones to ensure-X is that people are used to calling parse-X, so make sure you catch those in code review for the next while and try to educate your team on the change.

Honestly might be worthwhile to exclude the clojure core ones for a while just so that it ends up as a compile error rather than a bug.

That's a good point. I'm currently handling that by doing this in stages, where I'm changing all of the function names now, and then once this is merged and in use for a week or more, I'm gonna update to clojure 1.11, so in that middle period we'll catch anyone making mistakes. Might not be enough tho.

sounds like a good start

https://clojurians.slack.com/archives/C03S1KBA2/p1654280379777659

thanks Eugene 🙂

I have this snippet in user.clj:

(defmethod print-method clojure.lang.IPersistentMap [m, ^java.io.Writer w]
  "From "
  (#'clojure.core/print-meta m w)
  (#'clojure.core/print-map m #'clojure.core/pr-on w))

this is awesome, thanks @U9E8C7QRJ

Whether they have a message or not depends on how they are invoked right? You mean the cases when JDK itself throws these exceptions internally with no message?

My naive search to get some esoteric ones, using ripgrep in JDK git repo

cd jdk/src/java.base

rg --files-with-matches 'class .* extends [a-zA-Z0-9]*Exception' | xargs rg --files-without-match 'super' | xargs rg --files-without-match 'getMessage\('

share/classes/java/util/IllegalFormatException.java
share/classes/java/util/EmptyStackException.java
share/classes/java/io/OptionalDataException.java
share/classes/java/util/FormatterClosedException.java
share/classes/sun/reflect/annotation/TypeNotPresentExceptionProxy.java
share/classes/sun/reflect/generics/reflectiveObjects/NotImplementedException.java
share/classes/sun/reflect/annotation/AnnotationTypeMismatchExceptionProxy.java
share/classes/sun/reflect/annotation/EnumConstantNotPresentExceptionProxy.java
share/classes/jdk/internal/org/objectweb/asm/tree/UnsupportedClassVersionException.java

rg 'throw new ArrayIndexOutOfBoundsException\(\)'

share/classes/java/io/ObjectInputStream.java
4107:                    throw new ArrayIndexOutOfBoundsException();

share/classes/jdk/internal/misc/Unsafe.java
1327:            throw new ArrayIndexOutOfBoundsException();
2424:            throw new ArrayIndexOutOfBoundsException(); 

Yeah it was a fluke that the front end ignored the presence of a stack trace and some other info and solely checked for an error message. It's been corrected but I was just interested.

Also isn't the message implementation-defined? I'd consider it dangerous to rely on because it could change depending on the java version or if you're using oracle jdk vs openjdk vs temurin vs graal

Yeah I agree. It was an oversight. Fixed now. But I was wanting a list of error types that we were susceptible to on the jdk. But of course database drivers can throw errors with no message in some cases I'm sure

Plus lots of user or library code that uses core java exception types. I know I use them myself quite frequently, and sometimes don't include messages if the error should be obvious from the type alone.