JS Backend: Long_fromNumber does not gracefully support NaN

[McMurat]

When converting a double to a long the conversion may fail when the double is a NaN:

RangeError: The number NaN cannot be converted to a BigInt because it is not an integer at BigInt (<anonymous>) at Long_fromNumber

Expected behaviour: Return 0L instead.

[konsoletyper]

Note that fixing this may affect performance. Since such situation is quite rare, I doubt if it worth fixing. Also, did you try WasmGC backend?

[McMurat]

I think this case is not uncommon and can also happen rather "randomly" if some computation gets numerical instable. I really like that TeaVM is respecting the Java Language Specification to a high level, so it would be nice if this would be no exception.

If you are scared of the extra isNaN check, then it would also be possible to wrap the BigInt constructor in a try { ... } catch { return BigInt(0) }.

Unfortunately, I am running libgdx and cannot use WasmGC backend yet as I am also relying on the JS multithread feature.

[konsoletyper]

I think this case is not uncommon and can also happen rather "randomly" if some computation gets numerical instable

I have another opinion regarding this. Also, it's quite easy to fix on source code level: you can insert additional if (isNaN) in your Java/Kotlin code.

I really like that TeaVM is respecting the Java Language Specification to a high level

No, TeaVM has a lots of places where it violates this. For example, TeaVM does not produce fair NPE, CCE or AAIOBE by default. Also, there are lots of edge cases like integer zero division, etc. GWT, j2cl, Kotlin/JS - all behave the same way, sacrificing some rare edge cases for performance.

If you are scared of the extra isNaN check, then it would also be possible to wrap the BigInt constructor in a try { ... } catch { return BigInt(0) }.

No, this would kill performance even further.

[McMurat]

It's just complicated when these things occur in third party dependencies where you cannot add these extra checks.

I know that integer zero division, NPE, CCE, ... are not handled correctly. But these are all cases which would throw in a real JVM and are widely considered as programmer's faults. It's very rare and very bad practice to rely on these exceptions for control flow. But here it's different. TeaVM throws although a JVM would not.