-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
doc: improve example for Error.captureStackTrace() #46886
doc: improve example for Error.captureStackTrace() #46886
Conversation
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.
I see why you suggest this. I am not certain if the example becomes more difficult to read though, especially as it has new implications as outlined in my comment.
Should we maybe add a suggestion to use |
I understand the readability concern. Essentially it's a trade-off between having a 'copyable' example and a readable one. It would be interesting to find out if there are packages on npm that contain this error implementation... |
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.
I am hesitant to change the documentation like that as we mix different APIs and errors should ideally not be created like that in the first place.
What about changing the example to show how to hide multiple call sites? E.g.,
function a() {
b();
}
function b() {
c();
}
function c() {
// Create an error without stack trace to avoid calculating the stack trace twice.
const { stackTraceLimit } = Error;
Error.stackTraceLimit = 0;
const error = new Error();
Error.stackTraceLimit = stackTraceLimit;
// Capture the stack trace above function b
Error.captureStackTrace(error, b); // Neither function c, nor b is included in the stack trace
throw error;
}
That way we create a "real" error and only change it's stack trace accordingly.
I like this example a lot. It illustrates the usage of the function much better. But shouldn't the last line be |
Is there anything else I need to do to so this can get merged? |
Could you rebase and update the first commit message, it seems the description exceeds the size limit of 72 |
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.
The example looks good, would also wait for @BridgeAR 's review to see if the changes address all his concerns.
Change the `MyError` example so that instances of `MyError`are `instanceof Error` and also native errors when checked with `util.types.isNativeError()`. Co-authored-by: Ruben Bridgewater <ruben@bridgewater.de>
c4b05b3
to
7d8b38f
Compare
I've squashed all the commits and added line breaks. |
Landed in 38e6ac7 |
Change the `MyError` example so that instances of `MyError`are `instanceof Error` and also native errors when checked with `util.types.isNativeError()`. Co-authored-by: Ruben Bridgewater <ruben@bridgewater.de> PR-URL: #46886 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Debadree Chatterjee <debadree333@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Change the `MyError` example so that instances of `MyError`are `instanceof Error` and also native errors when checked with `util.types.isNativeError()`. Co-authored-by: Ruben Bridgewater <ruben@bridgewater.de> PR-URL: #46886 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Debadree Chatterjee <debadree333@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Change the `MyError` example so that instances of `MyError`are `instanceof Error` and also native errors when checked with `util.types.isNativeError()`. Co-authored-by: Ruben Bridgewater <ruben@bridgewater.de> PR-URL: #46886 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Debadree Chatterjee <debadree333@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Change the `MyError` example so that instances of `MyError`are `instanceof Error` and also native errors when checked with `util.types.isNativeError()`. Co-authored-by: Ruben Bridgewater <ruben@bridgewater.de> PR-URL: #46886 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Debadree Chatterjee <debadree333@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Change the
MyError
example so that instances ofMyError
areinstanceof Error
and also native errors when checked withutil.types.isNativeError()
.