Skip to content
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

Closed
wants to merge 1 commit into from

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