-
-
Notifications
You must be signed in to change notification settings - Fork 645
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cider error handling broken by Clojure 1.10.0-alpha7 #2443
Comments
The error messaging being parsed in 10 alpha 7 is
vs 1.9
The parsing is:
and is nil on the 1.10 message. |
Unless I'm missing something, in this case it seems that some valuable information is now missing from the error message. I'm fine with changing CIDER to support the new format, but I really want us to have some meaningful errors we can parse for our users. Let's also ping @puredanger for input. |
We've changed the root exception message in a number of cases (CLJ-2373 is the primary change). The important messages all still exist (although they may exist in different nested parts of the throwable chain. In this case you probably have a CompilerException wrapping an ExceptionInfo, which is a spec exception. The clojure.main repl is now doing more work to assemble parts of the exception chain into a more meaningful experience for a repl user based on the chain. Other tools (such as CIDER) can do the same. Some of this is exposed in clojure.main/ex-str (in 1.10.0-alpha7) but you can replicate what's happening there in whatever way you want in the CIDER repl. |
Sorry, meant to link: https://dev.clojure.org/jira/browse/CLJ-2373 |
I guess I should also mention that CompilerExceptions (as of 1.10.0-alpha7) also have ex-info data so you can use ex-data to extract data like error phase, file, line, column, symbol, etc. |
Thanks for the input, Alex! I think currently we just do some textual processing of the messages to make them clickable in the REPL, but I guess we can potentially expand on the checks to recover and display the important information. |
I think the new compiler exception ex-data, wrapping for macroexpansion cases, and moving away from burying data in strings is a substantially better place to be for tools. That said, that's you, so I'm interested in feedback as you move into using it. Here's an example. This is a compiler error and you will get a CompilerException wrapping a RuntimeException (that's all the same as all previous releases). The difference is that the CompilerException now supports ex-data and you can get to all the bits of important data as data. It's also doing less string building in the message of the root exception, however you can see that the messages are in the top and bottom messages of the chain. You can actually get a combined message by calling .toString() on the root too: user=> foo
Syntax error compiling at (0:0).
Cause: Unable to resolve symbol: foo in this context
user=> (ex-data *e)
#:clojure.error{:line 0, :column 0, :phase :compile, :source "NO_SOURCE_PATH"}
user=> (.toString *e)
"Syntax error compiling at (0:0).\nCause: Unable to resolve symbol: foo in this context"
user=> *e
#error {
:cause "Unable to resolve symbol: foo in this context"
:via
[{:type clojure.lang.Compiler$CompilerException
:message "Syntax error compiling at (0:0)."
:data #:clojure.error{:line 0, :column 0, :phase :compile, :source "NO_SOURCE_PATH"}
:at [clojure.lang.Compiler analyze "Compiler.java" 6799]}
{:type java.lang.RuntimeException
:message "Unable to resolve symbol: foo in this context"
:at [clojure.lang.Util runtimeException "Util.java" 221]}]
:trace
[[clojure.lang.Util runtimeException "Util.java" 221]
[clojure.lang.Compiler resolveIn "Compiler.java" 7397]
[clojure.lang.Compiler resolve "Compiler.java" 7341]
[clojure.lang.Compiler analyzeSymbol "Compiler.java" 7302]
[clojure.lang.Compiler analyze "Compiler.java" 6759]
[clojure.lang.Compiler analyze "Compiler.java" 6736]
[clojure.lang.Compiler eval "Compiler.java" 7164]
[clojure.lang.Compiler eval "Compiler.java" 7123]
[clojure.core$eval invokeStatic "core.clj" 3206]
[clojure.core$eval invoke "core.clj" 3202]
[clojure.main$repl$read_eval_print__8766$fn__8769 invoke "main.clj" 299]
[clojure.main$repl$read_eval_print__8766 invoke "main.clj" 299]
[clojure.main$repl$fn__8775 invoke "main.clj" 322]
[clojure.main$repl invokeStatic "main.clj" 322]
[clojure.main$repl_opt invokeStatic "main.clj" 386]
[clojure.main$main invokeStatic "main.clj" 485]
[clojure.main$main doInvoke "main.clj" 448]
[clojure.lang.RestFn invoke "RestFn.java" 397]
[clojure.lang.AFn applyToHelper "AFn.java" 152]
[clojure.lang.RestFn applyTo "RestFn.java" 132]
[clojure.lang.Var applyTo "Var.java" 705]
[clojure.main main "main.java" 37]]}``` |
Sure. Btw, is there any special reason for punctuation/language used in:
Seems to me it'd be nice if
(I'm surprised about the |
First line format is generally: The location has been using (SOURCE:LINE:COL) for a long time to report Clojure source errors. We are now omitting the first part when at the repl (you'll still see the source referring to a Clojure file if it's coming from a file). In general, I'd rather say nothing than something that is the same in every error, which has no informational value. If anything, you could argue the line and column info here are probably not even useful (as "line" is actually the nth repl invocation). The CompilerException message is only a descriptive wrapper about the circumstances in which the error was caught so you are welcome to make your own message out of the pieces provided in the ex-info data! That is, when a CompilerException is constructed, it has no message of its own - the message is just a template constructed from the other ex data, which you have. The second line is of the form |
Thanks for the detailed explanations, Alex!
I don't quite get this. Are they actually the line and column relative to the current prompt? This is certainly very useful information if you're working on a rich REPL.
Got it. Could you discuss with him if he's open to changing those? I don't care that much about the punctuation being ideal, but I feel it'd be nice if at least symbol references stood out more in error messages. |
FWIW I think this is a great addition for tooling user=> (ex-data *e)
#:clojure.error{:line 0, :column 0, :phase :compile, :source "NO_SOURCE_PATH"} |
It is, but we have to think how exactly to implement this. You can not just call |
I guess it'd be simplest to just tune |
It would be interesting to know if this was solved by |
@slipset You and me both. Can you test this? |
WIth
I see
|
I think you need to do some interactive eval to see if the error highlighting and the stacktrace buffer look OK. |
Hmm,
is enough to repro the problem. But here is some more evaluated stuff:
Let me know if there are specific things you'd want me to test. |
Source buffer. :-) The problem is that because of the changed format of the error messages they were not properly parsed and the cider-error buffer would not work. REPL evaluations don't trigger the stacktrace buffer. |
FYI, there will be some additional changes coming in https://dev.clojure.org/jira/browse/CLJ-2420 for the next 1.10 pre-release (not sure if they affect the current code as well). |
Having the same error with:
looks like it happens because source location not set with I see also that I'll try to add info from |
Now that 1.10 is out, I am hoping this can get sorted out? (I know, jump in and do it myself, but I am already sacrificing sleep for my own free open-source projects, I don’t have the spare cycles! 😂 ) |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution and understanding! |
This issues been automatically closed due to lack of activity. Feel free to re-open it if you ever come back to it. |
Expected behavior
When trying to evaluate a form with an error at compile time, or instance evaling a symbol that wasn't
def
'd, a*cider-error*
buffer should pop up with a message like:This is working on all clojure versions up to and including
1.10.0-alpha6
Actual behavior
On the newly released
1.10.0-alpha7
no*cider-error*
buffer appears and this stacktrace is printed to the repl buffer:Looking at clojure's changelog, I believe it's likely that CLJ-2386 was the culprit for the breaking change.Steps to reproduce the problem
Eval a symbol
foo
in an otherwise blank clojure buffer while running clojure1.10.0-alpha7
CIDER version information
Include here the version string displayed when
CIDER's REPL is launched. Here's an example:
Emacs version
27.0.50
Operating system
Linux
The text was updated successfully, but these errors were encountered: