-
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
worker: use correct ctor for error serialization #25951
Conversation
When serializing errors, use the error constructor that is closest to the object itself in the prototype chain. The previous practice of walking downwards meant that `Error` would usually be the first constructor that is used, even when a more specific one would be available/appropriate, because it is the base class of the other common error types.
@@ -86,7 +86,7 @@ function serializeError(error) { | |||
if (typeof error === 'object' && | |||
ObjectPrototypeToString(error) === '[object Error]') { | |||
const constructors = GetConstructors(error); | |||
for (var i = constructors.length - 1; i >= 0; i--) { | |||
for (var i = 0; i < constructors.length; i++) { |
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.
Maybe for (const name of constructors)
?
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.
@gengjiawen The idea here is that this code is supposed to be as robust against monkey-patching as possible, because we do not want to generate more exceptions while attempting to handle another exception – with for (const … of …)
, it’s possible to override Array.prototype[Symbol.iterator]()
and give false results or throw another exception.
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.
Thanks for the explain :)
Landed in de9d5ff |
When serializing errors, use the error constructor that is closest to the object itself in the prototype chain. The previous practice of walking downwards meant that `Error` would usually be the first constructor that is used, even when a more specific one would be available/appropriate, because it is the base class of the other common error types. PR-URL: #25951 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Minwoo Jung <minwoo@nodesource.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
When serializing errors, use the error constructor that is closest to the object itself in the prototype chain. The previous practice of walking downwards meant that `Error` would usually be the first constructor that is used, even when a more specific one would be available/appropriate, because it is the base class of the other common error types. PR-URL: #25951 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Gus Caplan <me@gus.host> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Minwoo Jung <minwoo@nodesource.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
When serializing errors, use the error constructor that is
closest to the object itself in the prototype chain.
The previous practice of walking downwards meant that
Error
would usually be the first constructor that is used,even when a more specific one would be available/appropriate,
because it is the base class of the other common error types.
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes