stacktrace information missing/incorrect in some cases
Closed this issue · 2 comments
version
org.babashka/sci 0.8.43
(Issue demonstrated below with babashka v1.4.192)
platform
JVM, openjdk version "11.0.24"
problem
Some exceptions thrown during the realization of a lazy sequence (e.g. from for, map etc) are missing the right line information in the stacktraces, while other exceptions have correct stacktraces. This indicates there might be some room for improvement in the reported stacktrace and therefore the developer experience during debugging. During inspection of the problem I found that a similar issue is present for let.
(More background context in Slack thread)
repro
The following exception cannot be pinpointed to the destructuring of the for, or just the for itself
bb -e '(str (for [[a] 1] a))'
...
1: (str (for [[a] 1] a))
^--- Don't know how to create ISeq from: java.lang.Long
While the following exception gets very precise reporting
bb -e '(str (for [a [1]] (/ a 0)))'
...
1: (str (for [a [1]] (/ a 0)))
^--- Divide by zero
After some digging I found that a similar problem happens with let itself, the thing that for might be relying on for this.
bb -e '(str (let [[a] 1] a))'
...
1: (str (let [[a] 1] a))
^--- nth not supported on this type: Long
vs very precise:
bb -e '(str (let [_ (/ 1 0)]))'
...
1: (str (let [_ (/ 1 0)]))
^--- Divide by zero
expected behavior
I would like to see stacktrace information closer to the actual cause. Right now it can be very far away (think of a lazy sequence realized in a different section of your code). To be specific I would hope for a very exact pinpointing of the exception, e.g. in the case of let:
bb -e '(str (let [[a] 1] a))'
...
1: (str (let [[a] 1] a))
^--- nth not supported on this type: Long
Probably the best we can do is point to the location of for since vector aren't read with any location metadata. Would that be an improvement to you?
Yes, that's definitely a big improvement and helpful enough to easily find the cause of an error.