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

lib: new error implementation #18857

Closed
wants to merge 7 commits into from
Closed

Conversation

BridgeAR
Copy link
Member

@BridgeAR BridgeAR commented Feb 18, 2018

This implements a function based error system. Instead of passing in the
error code as first argument, the error code itself is a error class.
It already contains the correct error type, so while adding a new
error no one has to think about the error type anymore. In case a
single error code has more than one error type, the error class has
properties for the non default error types. Those can be used as
fallback.

This prevents typos, makes the implementation easier and it is less
verbose when writing the code for a new error.

The implementation itself does not interfere with the old
implementation. So the old and the new system can co-exist and it is
possible to slowly migrate the old ones to the new system.

By doing this I also realized that there are multiple error codes that
are currently not used at all. I also found other mistakes where a
wrong error type was in place.

So far this is only WIP and I wanted to get some feedback.

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines
Affected core subsystem(s)

lib

@nodejs-github-bot nodejs-github-bot added console Issues and PRs related to the console subsystem. errors Issues and PRs related to JavaScript errors originated in Node.js core. module Issues and PRs related to the module subsystem. labels Feb 18, 2018
@BridgeAR BridgeAR added the wip Issues and PRs that are still a work in progress. label Feb 18, 2018

get name() {
return `${super.name} [${key}]`;
}
Copy link
Member

Choose a reason for hiding this comment

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

In this case we might also want to create a static get name() so that the class itself can be disambiguated from other classes of this type?

Copy link
Member

Choose a reason for hiding this comment

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

Or even better, NodeError.name = ....

Copy link
Member Author

Choose a reason for hiding this comment

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

I thought about this a few times now and I decided not to do that out of the following reasons:

  1. We only use the class internal and do not expose it directly.
  2. The main class has sub classes as properties and those should make it easy to identify the correct one.
  3. If we add the name, the original NodeError name will not be there and I think it should be.

return key;
}

set code(value) {
Copy link
Member

Choose a reason for hiding this comment

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

is there any use case for this?

Copy link
Contributor

Choose a reason for hiding this comment

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

My guess is that userland modules (not aware of the standardized node core error objects) may have already been setting this property to something else.

Copy link
Member

Choose a reason for hiding this comment

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

Yes, this was specifically asked for by userland module authors who need the ability to keep specifying their own codes.

Copy link
Member

@devsnek devsnek left a comment

Choose a reason for hiding this comment

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

lgtm with addaleax's comment addressed

@@ -35,12 +35,12 @@ function Console(stdout, stderr, ignoreErrors = true) {
return new Console(stdout, stderr, ignoreErrors);
}
if (!stdout || typeof stdout.write !== 'function') {
throw new errors.TypeError('ERR_CONSOLE_WRITABLE_STREAM', 'stdout');
throw new ERR_CONSOLE_WRITABLE_STREAM('stdout');
Copy link
Member

Choose a reason for hiding this comment

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

The only challenge I really have with this is that it makes it far less obvious what kind of error is being thrown here.

Copy link
Member Author

@BridgeAR BridgeAR Feb 19, 2018

Choose a reason for hiding this comment

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

That is also the charming side: you do not have to care about that as it was already taken care off in an earlier step. And we can verify much better that it actually has the correct type. Now you can see the types in the overview in the errors.js file. And I spotted multiple errors due to this.

This implements a function based system. Instead of passing in the
error code as first argument, the error code itself is a error class.
It already contains the correct error type, so while adding a new
error no one has to think about the error type anymore. In case a
single error code has more than one error type, the error class has
properties for the non default error types. Those can be used as
fallback.

This prevents typos, makes the implementation easier and it is less
verbose when writing the code for a new error.

The implementation itself does not interfere with the old
implementation. So the old and the new system can co-exist and it is
possible to slowly migrate the old ones to the new system.
This updates all internal errors to the new error type. While doing
so it removes unused errors.

A few errors currently seem to have the wrong type. To identify them
later, comments were added next to the error type.
This ports the errors to the new error system.
Some error types are not properly set. This adds comments which
ones are probably falty and to what they should be set instead.
@BridgeAR BridgeAR removed the wip Issues and PRs that are still a work in progress. label Feb 19, 2018
@BridgeAR
Copy link
Member Author

I updated all error codes and removed the breaking change. It can now be used for all error codes. I also added quite a few comments about wrong error types. Please have a look. I personally suggest to keep the comments for now and change those in a different PR as that is breaking.

CI https://ci.nodejs.org/job/node-test-pull-request/13264/

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

@joyeecheung joyeecheung left a comment

Choose a reason for hiding this comment

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

LGTM with a suggestion, thanks!

@@ -86,6 +87,54 @@ function makeNodeError(Base) {
};
}

function makeNodeError2(Base, key) {
Copy link
Member

Choose a reason for hiding this comment

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

Can this be renamed to something more descriptive e.g. makeNodeErrorWithCode?

@BridgeAR
Copy link
Member Author

@mhdawson one NAPI code got removed that was not used (ERR_NAPI_CONS_PROTOTYPE_OBJECT). I checked every code that I removed and there are no hits anywhere for that code besides in the docs and errors.js. You can spot all removed error codes easily by looking at the documentation (I removed all of those from the documentation as well).

@BridgeAR
Copy link
Member Author

I changed the name. Running a Light-CI just to verify the minor changes since the full CI:

https://ci.nodejs.org/job/node-test-commit-light/307/console

BridgeAR added a commit to BridgeAR/node that referenced this pull request Feb 22, 2018
This implements a function based system. Instead of passing in the
error code as first argument, the error code itself is a error class.
It already contains the correct error type, so while adding a new
error no one has to think about the error type anymore. In case a
single error code has more than one error type, the error class has
properties for the non default error types. Those can be used as
fallback.

This prevents typos, makes the implementation easier and it is less
verbose when writing the code for a new error.

The implementation itself does not interfere with the old
implementation. So the old and the new system can co-exist and it is
possible to slowly migrate the old ones to the new system.

PR-URL: nodejs#18857
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: Gus Caplan <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Joyee Cheung <[email protected]>
BridgeAR added a commit to BridgeAR/node that referenced this pull request Feb 22, 2018
This updates all internal errors to the new error type. While doing
so it removes unused errors.

A few errors currently seem to have the wrong type. To identify them
later, comments were added next to the error type.

PR-URL: nodejs#18857
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: Gus Caplan <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Joyee Cheung <[email protected]>
BridgeAR added a commit to BridgeAR/node that referenced this pull request Feb 22, 2018
This ports the errors to the new error system.

PR-URL: nodejs#18857
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: Gus Caplan <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Joyee Cheung <[email protected]>
BridgeAR added a commit to BridgeAR/node that referenced this pull request Feb 22, 2018
Some error types are not properly set. This adds comments which
ones are probably falty and to what they should be set instead.

PR-URL: nodejs#18857
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: Gus Caplan <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Joyee Cheung <[email protected]>
BridgeAR added a commit to BridgeAR/node that referenced this pull request Feb 22, 2018
PR-URL: nodejs#18857
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: Gus Caplan <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Joyee Cheung <[email protected]>
MayaLekova pushed a commit to MayaLekova/node that referenced this pull request May 8, 2018
PR-URL: nodejs#18857
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: Gus Caplan <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Joyee Cheung <[email protected]>
ChALkeR added a commit that referenced this pull request Jun 23, 2018
This restores a broken and erroneously removed error, which was
accidentially renamed to ERR_MISSING_DYNAMIC_INTSTANTIATE_HOOK (notice
the "INTST" vs "INST") in 921fb84
(PR #16874) and then had documentation and implementation removed under
the old name in 6e1c25c (PR #18857),
as it appeared unused.

This error code never worked or was documented under the mistyped name
ERR_MISSING_DYNAMIC_INTSTANTIATE_HOOK, so renaming it back to
ERR_MISSING_DYNAMIC_INSTANTIATE_HOOK is a semver-patch fix.

Refs: #21440
Refs: #21470
Refs: #16874
Refs: #18857
targos pushed a commit to ChALkeR/io.js that referenced this pull request Jun 30, 2018
This restores a broken and erroneously removed error, which was
accidentially renamed to ERR_MISSING_DYNAMIC_INTSTANTIATE_HOOK (notice
the "INTST" vs "INST") in 921fb84
(PR nodejs#16874) and then had documentation and implementation removed under
the old name in 6e1c25c (PR nodejs#18857),
as it appeared unused.

This error code never worked or was documented under the mistyped name
ERR_MISSING_DYNAMIC_INTSTANTIATE_HOOK, so renaming it back to
ERR_MISSING_DYNAMIC_INSTANTIATE_HOOK is a semver-patch fix.

Refs: nodejs#21440
Refs: nodejs#21470
Refs: nodejs#16874
Refs: nodejs#18857
targos pushed a commit that referenced this pull request Jun 30, 2018
This restores a broken and erroneously removed error, which was
accidentially renamed to ERR_MISSING_DYNAMIC_INTSTANTIATE_HOOK (notice
the "INTST" vs "INST") in 921fb84
(PR #16874) and then had documentation and implementation removed under
the old name in 6e1c25c (PR #18857),
as it appeared unused.

This error code never worked or was documented under the mistyped name
ERR_MISSING_DYNAMIC_INTSTANTIATE_HOOK, so renaming it back to
ERR_MISSING_DYNAMIC_INSTANTIATE_HOOK is a semver-patch fix.

Refs: #21440
Refs: #21470
Refs: #16874
Refs: #18857

PR-URL: #21493
Reviewed-By: Gus Caplan <[email protected]>
Reviewed-By: Trivikram Kamat <[email protected]>
Reviewed-By: Vse Mozhet Byt <[email protected]>
Reviewed-By: Tiancheng "Timothy" Gu <[email protected]>
Reviewed-By: Benjamin Gruenbaum <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Ron Korving <[email protected]>
Reviewed-By: Luigi Pinca <[email protected]>
targos pushed a commit that referenced this pull request Jul 3, 2018
This restores a broken and erroneously removed error, which was
accidentially renamed to ERR_MISSING_DYNAMIC_INTSTANTIATE_HOOK (notice
the "INTST" vs "INST") in 921fb84
(PR #16874) and then had documentation and implementation removed under
the old name in 6e1c25c (PR #18857),
as it appeared unused.

This error code never worked or was documented under the mistyped name
ERR_MISSING_DYNAMIC_INTSTANTIATE_HOOK, so renaming it back to
ERR_MISSING_DYNAMIC_INSTANTIATE_HOOK is a semver-patch fix.

Refs: #21440
Refs: #21470
Refs: #16874
Refs: #18857

PR-URL: #21493
Reviewed-By: Gus Caplan <[email protected]>
Reviewed-By: Trivikram Kamat <[email protected]>
Reviewed-By: Vse Mozhet Byt <[email protected]>
Reviewed-By: Tiancheng "Timothy" Gu <[email protected]>
Reviewed-By: Benjamin Gruenbaum <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Ron Korving <[email protected]>
Reviewed-By: Luigi Pinca <[email protected]>
@MylesBorins
Copy link
Contributor

Backport requested for 8.x in #19244

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. console Issues and PRs related to the console subsystem. errors Issues and PRs related to JavaScript errors originated in Node.js core. module Issues and PRs related to the module subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants