Repository navigation
Crash when error.name is not a string #30572
Description
Activity
Seems like maybe
inspect()can make sure to convert.nameto a string before doing anything with it? Going to guess that this would be of interest to @BridgeAR.- addedutilIssues and PRs related to the built-in util module.Issues and PRs related to the built-in util module.
on Nov 21, 2019 I should add, if the team thinks this is something node should patch, I'm more than happy to work up a PR.
I think it’s definitely something that Node.js should patch, so feel free to open a PR.
I also wonder why we have a
.endsWith('Error')check in the first place – it’s not clear to me what exactly the code guarded by it does, but the check seems brittle and I wonder if there’s a better option?You might also want to test the condition that
.stackis not a string, I think it should fail similarly.- addedconfirmed-bugIssues and PRs for confirmed bugs.Issues and PRs for confirmed bugs.
on Nov 21, 2019 I wonder why we have a .endsWith('Error') check in the first place
The check identifies subclassed errors without direct own name property. The subclass name will then show up in the output. It tries to be very conservative by only visualizing the subclass name in case the errors name and stack have not been tampered with.
class SubError extends Error {} console.log(new SubError('foo')) // SubError: foo // at ... // It will also highlight the actual name and the subclass name in case they are not aligned. class FooBar extends Error{} console.log(new FooBar('foo')) // FooBar [Error]: foo // at ... // Without this check both cases would be printed as: // Error: foo // at ...
the check seems brittle and I wonder if there’s a better option?
Errors are pretty much the most difficult to inspect object type. They can have lots of shapes and it's quite difficult to always provide the best output (e.g., the stack property and the name and message could deviate from each other).
If someone finds a better way to get this right, that would be great!- added a commit that references this issue
on Nov 25, 2019 - added a commit that references this issue
on Nov 26, 2019 Thank you, all, for the responsiveness and prompt followup!
- added a commit that references this issue
on Dec 1, 2019 Any plan to ship the patch to v12?
@cuyl it should be published in one of the upcoming releases.
Reacted by YuChao Liang- added a commit that references this issue
on Jul 22, 2020
v12.13.0.Darwin will.local 18.7.0 Darwin Kernel Version 18.7.0: Sat Oct 12 00:02:19 PDT 2019; root:xnu-4903.278.12~1/RELEASE_X86_64 x86_64internal/util/inspect.jsThe following program crashes on node
v12.13.0:error-12.jswith the following logged:
On node
v10.15.1, the program doesn't crash and instead logs:I appreciate that node might not consider this a bug that is theirs to fix (the
nameproperty being non-string could be viewed as a userland error), but wanted to file the issue in case it was concerning.I discovered this doing an upgrade to node 12--it turns out the official aws-sdk will set the
nameproperty of HTTP response errors to the numeric HTTP response code.I suspect this was introduced in e54f237.