-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
Conversation
|
||
get name() { | ||
return `${super.name} [${key}]`; | ||
} |
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.
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?
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.
Or even better, NodeError.name = ...
.
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.
I thought about this a few times now and I decided not to do that out of the following reasons:
- We only use the class internal and do not expose it directly.
- The main class has sub classes as properties and those should make it easy to identify the correct one.
- If we add the name, the original
NodeError
name will not be there and I think it should be.
return key; | ||
} | ||
|
||
set code(value) { |
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.
is there any use case for this?
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.
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.
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.
Yes, this was specifically asked for by userland module authors who need the ability to keep specifying their own codes.
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.
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'); |
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.
The only challenge I really have with this is that it makes it far less obvious what kind of error is being thrown here.
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.
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.
df999dc
to
474c498
Compare
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. |
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.
LGTM with a suggestion, thanks!
lib/internal/errors.js
Outdated
@@ -86,6 +87,54 @@ function makeNodeError(Base) { | |||
}; | |||
} | |||
|
|||
function makeNodeError2(Base, key) { |
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.
Can this be renamed to something more descriptive e.g. makeNodeErrorWithCode?
@mhdawson one NAPI code got removed that was not used ( |
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 |
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]>
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]>
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]>
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]>
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]>
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]>
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
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
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]>
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]>
Backport requested for 8.x in #19244 |
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), orvcbuild test
(Windows) passesAffected core subsystem(s)
lib