fix: print error when internal cli error happens (more helpful than ERROR: null) #5344
Conversation
|
|
|
Switching to draft pending #5078 (comment). We can't review without a reproduction, and it might be that all buggy behavior was already fixed? Thanks for the PR in the interim though! |
For clarity, this is not about fixing whatever that triggered the error, but about improving the logged diagnostics information when an error (unexpectedly) happens. While the specific trigger was fixed, it is still possible to end up in this case if some other internal error occurs. If you want to reproduce locally, you could throw an error from Line 377 in abf3dd9 There are probably other ways to trigger this issue, but I haven't looked. If you are concerned about logging too much information (when an error message is already present), I could add a check to only log the error when the message is null. |
There was a problem hiding this comment.
Pull Request Overview
This PR enhances error reporting in the CLI by printing the original error object to stderr when an internal error occurs, making the “ERROR: null” message more informative.
- Prints the caught error object after showing help and the generic error message.
- Exits with status code 1 after logging the full error.
Comments suppressed due to low confidence (1)
lib/cli/cli.js:64
- Add a test case that simulates an internal CLI error to verify that the original error message (or stack) is printed as expected.
console.error(err);
lib/cli/cli.js
Outdated
| debug('caught error sometime before command handler: %O', err); | ||
| yargs.showHelp(); | ||
| console.error(`\n${symbols.error} ${pc.red('ERROR:')} ${msg}`); | ||
| console.error(err); |
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
JoshuaKGoldberg
left a comment
There was a problem hiding this comment.
@Rob--W #5078 is open and I see that you were right all along 🙂. I think this PR is ready for un-drafting - and pretty close to ready for merge. WDYT about the suggested change? And, mind if we un-draft this?
Normally I'd request test coverage but for an edge case like this that "shouldn't" ever happen, I think it's reasonable to skip testing.
lib/cli/cli.js
Outdated
| console.error(`\n${symbols.error} ${pc.red('ERROR:')} ${msg}`); | ||
| console.error(err); |
There was a problem hiding this comment.
[Bug] Most of the, the msg is actually enough on its own. So I don't think we'd want to log the full err - that'd be a lot of extra unnecessary output.
How about only logging err if msg is falsy? Treating it as a kind of targeted backup?
| console.error(`\n${symbols.error} ${pc.red('ERROR:')} ${msg}`); | |
| console.error(err); | |
| console.error(`\n${symbols.error} ${pc.red('ERROR:')} ${msg || err}`); |
There was a problem hiding this comment.
[Bug] Most of the, the
msgis actually enough on its own. So I don't think we'd want to log the fullerr- that'd be a lot of extra unnecessary output.
Not logging the error when msg is set sounds reasonable to me. I called that out as an option before, at #5344 (comment)
How about only logging
errifmsgis falsy? Treating it as a kind of targeted backup?Suggested change
console.error(`\n${symbols.error} ${pc.red('ERROR:')} ${msg}`); console.error(err); console.error(`\n${symbols.error} ${pc.red('ERROR:')} ${msg || err}`);
The above could work but would hide the fact that this is an internal error, and also loses the stack trace (which is valuable for debugging). I was thinking of the following:
| console.error(`\n${symbols.error} ${pc.red('ERROR:')} ${msg}`); | |
| console.error(err); | |
| console.error(`\n${symbols.error} ${pc.red('ERROR:')} ${msg}`); | |
| if (!msg) { | |
| console.error(err); | |
| } |
I did intentionally not stringify the error (or even assume that it is an Error instance). We are in very bad territory, and dumping the raw value (an Error preferably, but could be any promise rejection or thrown value in theory) allows the reader to debug the issue.
There was a problem hiding this comment.
Yeah that makes sense. I'm in favor :)
There was a problem hiding this comment.
+1 to the having stack trace, as that made it possible to debug #5562 much simpler.
There have been issues where the reported error is "ERROR: null", which is very unhelpful. Here is an analysis of a specific example: mochajs#5048 (comment) Although the trigger for that error was fixed by mochajs#5074, the unhelpfulness of "ERROR: null" was not addressed. To help with debugging, this patch prints the original error when this stage is unexpectedly reached.
7cda07e to
9f1fad1
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #5344 +/- ##
==========================================
- Coverage 93.52% 93.50% -0.02%
==========================================
Files 57 57
Lines 4465 4467 +2
Branches 918 919 +1
==========================================
+ Hits 4176 4177 +1
- Misses 289 290 +1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Hey @Rob--W, could you add a new unit test for this? Something that would've failed on main but passes with your changes? |
PR Checklist
ERROR: nullpart of it)status: accepting prsOverview
There have been issues where the reported error is "ERROR: null", which is very unhelpful. Here is an analysis of a specific example: #5048 (comment)
Although the trigger for that error was fixed by #5074, the unhelpfulness of "ERROR: null" was not addressed.
To help with debugging, this patch prints the original error when this stage is unexpectedly reached.