Skip to content

worker: use correct ctor for error serialization - #25951

Closed
addaleax wants to merge 1 commit into
nodejs:masterfrom
addaleax:worker-error-ctor
Closed

worker: use correct ctor for error serialization#25951
addaleax wants to merge 1 commit into
nodejs:masterfrom
addaleax:worker-error-ctor

Conversation

@addaleax

@addaleax addaleax commented Feb 5, 2019

Copy link
Copy Markdown
Member

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 the worker_threads module and Worker API. 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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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

addaleax commented Feb 8, 2019

Copy link
Copy Markdown
Member Author
@addaleax addaleax added the author ready PRs with CI started, the required approvals, and no outstanding review comments. label Feb 8, 2019
@addaleax

addaleax commented Feb 8, 2019

Copy link
Copy Markdown
Member Author

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 <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>
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 <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>
@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 with CI started, the required approvals, and no outstanding review comments. worker Issues and PRs related to the worker_threads module and Worker API.

8 participants