Clojurians Log v2
nrepl 2022-08-11
Does nREPL have something for displaying stacktraces, e.g. by sending over stack trace data? Right now the stacktrace with babashka + CIDER isn't very useful, but bb does have useful data that it could send to the client
This is how the exception now displays. The ex-data contains the interpreter stacktrace
cc @bozhidar
The only built-in facility currently is ex-info. cider-nrepl has an additional stracktrace middleware that can display structured stack traces, though. Both ex-info and stacktrace predate the addition of the rich ex-data that was added around Clojure 1.10 if I recall correctly.
ex-data the function in clojure or is this something in nREPL?
@bozhidar Let's start with the most simple thing though: how do I communicate the file, line and column of an error to an nREPL client in 2022?
That already doesn't work properly for bb
Out of the box currently you can only supply an exception class and an error message for the failed eval:
(<--
id "25"
session "bdae3a62-a52e-46d4-959a-4ea1f6d1a735"
time-stamp "2022-08-12 09:31:02.571684633"
err "ArithmeticException Divide by zero clojure.lang.Numbers.divide (Numbers.java:158)
"
)
(<--
id "25"
session "bdae3a62-a52e-46d4-959a-4ea1f6d1a735"
time-stamp "2022-08-12 09:31:02.574206251"
ex "class java.lang.ArithmeticException"
root-ex "class java.lang.ArithmeticException"
status ("eval-error")
)The expectation is that clients will parse the err message and extract the filename and the location from it.
Probably it'd be nice if we made this more flexible and made it possible to return the map with exception metadata as well, so newer clients would use it instead. (e.g. there could ex-data is the second eval-error message)
The thing I'd be interested in is have a data-driven way to make CIDER highlight the error in the right location in the babashka script
This info is normally not on the ex-data
CIDER parses the err message (using a regular expression) and uses it to highlight an entire line as the cause of the exception. In the presence of the stacktrace middleware it gets more precise data from it.
So if bb.nrepl printed the error in this format, it should work. I'll give that a try
hmm wait
in ArithmeticException Divide by zero clojure.lang.Numbers.divide (Numbers.java:158) there is no reference to the user's clojure file where the error happened
so how is that going to work
Bad example I guess - for most exceptions there's actually file in which the exception was raised. Probably / is defined in Numbers.java.
Perhaps nREPL can work harder to find the most relevant frame of the stacktrace - I guess that was the top frame and that's what we use by default. I haven't looked at this code in ages, so I don't remember well how it works at this point.
Some examples from the tests in CIDER how we use this https://github.com/clojure-emacs/cider/blob/65a23e54227e3575f5a909dcfbdbbaef70d1438b/test/cider-error-parsing-tests.el