I’m not sure if I’ve flipped some switch accidentally, but exceptions surface without details (stack trace, most notably) when running from the REPL. Ie., this is all the info I get:
Execution error (ExceptionInfo) at co.multiply.app.util.anomaly/anomaly-exception (anomaly.cljc:234).
Cannot invoke "java.lang.Number.doubleValue()" because "x" is null
If I want more, I have to surround the command in a try/catch and log the exception object.
Have I screwed up some config?Right, to be clear, I’m not typing things manually into the REPL window, I’m sending forms. Both are similarly stripped down versions, at least for me. Yeah, I understand that they can be overwhelming for people. I have a lot of async code though, and usually the stacktraces are shorter than I would like anyway, so I kind of need them.
@mgardner2 *e works pretty well (I think). Didn’t the inline version use to have this detail included previously?
I'll check this, because I'm sure I usually get the trace inline.
I don't think there are any flags for this - just to be clear, you're talking about what you see in the REPL output pane, right? Not inline in the editor.
Right. The editor pops up the same message:
Ok, I'll check that tomorrow.
Could be this? https://www.metosin.fi/blog/missing-stacktraces
That could absolutely be it: I can see that it’s been added to the deps.edn.
i think the advice in the Metosin article is out of date now that Clojure CLI sets the JVM flag by defulat since version 1.11.1.1208: https://clojure.atlassian.net/browse/TDEPS-234.
Ah, gotcha. Yeah, removing it made no difference.
Thanks for looking into it. I think I’ve seen more fully fledged, browseable exceptions after 1.10, but maybe I’m misremembering. Does this mean that this is not unique to me? You see the same?
@henrik I assume you're aware of *e?
> Does this mean that this is not unique to me? You see the same?
Yes, but with a caveat - I hadn't seen this for a long time because I use the inline REPL almost exclusively these days, which renders the exceptions differently. If I do need to use the REPL view for some reason, I use *e. But I think it's true that I do that basically every time I see an exception.
This is a bit of a tricky one - the core team removed the stack traces on every exception because so many people complained about seeing them. It's definitely a bit of a damned if you do, damned if you don't situation.
For Cursive, I think I can add a config flag to specify which behaviour you want - perhaps none, prettified or full Java-style.
Sorry for the delay, I went through and checked this. Cursive is actually reproducing what the standard clojure.main REPL does since 1.10, which triages the exception and only prints the error message. However, in Clojure itself you can get the Full report at: /tmp/...edn using -M -e, Cursive should probably provide something similar.
Does Cursive do anything to interact with IntelliJ's 'Optimize Imports' command? It seems to work very nicely, except that it and clj-kondo seem to disagree about the ordering of the following cljs requires:
[goog.crypt.Sha1]
[goog.crypt.base64 :as b64]
I assume it is case-related. It's lightly sub-optimal as we have to avoid optimizing those imports (which is frequently useful) to not break the linter.
clojure-lsp also agrees with what clj-kondo does I believe
Yes, that's Cursive's implementation, I'll check that and fix.