-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
util: add support for error subclassing and null prototype #23852
Conversation
0533079
to
5887e9f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a good start but I am a bit afraid about manipulating manually created error stacks.
Would you be so kind and add a test for a case similar to this:
class CustomError extends TypeError {
constructor(message) {
super(message);
const stack = this.stack.split('\n');
stack.shift();
this.stack = `Awesome stack: message\n${stack.join('\n')}`;
}
}
const err = new CustomError('foobar');
...
It is very hard to tell what the user intention was or was not. Therefore I suggest to check for if the original start is the name of one of the classes this error inherited from. That way we are safe to replace things we are certain about.
Something similar about the null prototype: I would use a regular expression to add the null prototype information instead of using indexOf()
. The user could definitely have used some special information. I would probably go for /^[a-z_-]+: /i
but maybe we want to be more conservative and go for /^[a-z_-]*Error: /i
.
@BridgeAR : Quick question, for the given example:
If we do our check with parent error type, then we would keep the stack as it is like:
but I think, we need to print:
What do you think? Or is it ok, for the user to show them what they need? |
@BridgeAR Ping :) |
@BridgeAR Friendly remainder 🔉 |
@BridgeAR friendly ping again... |
@BridgeAR Sorry, but one more very gentle ping.. :) |
Object.setPrototypeOf(customErr, null); | ||
assert.ok(util.inspect(customErr) | ||
.includes('[Error: null prototype]')); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This case is a duplicate of the test above.
I have to give this one a bit more thought. Sadly, there are lots and lots of edge cases that could happen with errors. |
Superseded by #26923. It could still be expanded but I would not want to do that before Node.js v13. |
Handle error subclassing and null prototypes on error.
/cc @BridgeAR
make -j4 test
(UNIX), orvcbuild test
(Windows) passes