Skip to content

Conversation

addaleax
Copy link
Member

@addaleax addaleax commented Feb 5, 2019

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), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines

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.
@nodejs-github-bot
Copy link
Collaborator

@addaleax addaleax added the worker Issues and PRs related to Worker support. label Feb 5, 2019
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++) {
Copy link
Member

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) ?

Copy link
Member Author

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the explain :)

@addaleax
Copy link
Member Author

addaleax commented Feb 8, 2019

@addaleax addaleax added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Feb 8, 2019
@addaleax
Copy link
Member Author

addaleax commented Feb 8, 2019

Landed in de9d5ff

@addaleax addaleax closed this Feb 8, 2019
@addaleax addaleax deleted the worker-error-ctor branch February 8, 2019 20:31
addaleax added a commit that referenced this pull request Feb 8, 2019
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 <[email protected]>
Reviewed-By: Gus Caplan <[email protected]>
Reviewed-By: Benjamin Gruenbaum <[email protected]>
Reviewed-By: Minwoo Jung <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
addaleax added a commit that referenced this pull request Feb 8, 2019
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 <[email protected]>
Reviewed-By: Gus Caplan <[email protected]>
Reviewed-By: Benjamin Gruenbaum <[email protected]>
Reviewed-By: Minwoo Jung <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
@targos targos mentioned this pull request Feb 14, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

author ready PRs that have at least one approval, no pending requests for changes, and a CI started. worker Issues and PRs related to Worker support.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants