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: set properties in error #26752

Closed
wants to merge 3 commits into from

Conversation

BridgeAR
Copy link
Member

Please have a look at the commit messages for a proper description.

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

@nodejs-github-bot nodejs-github-bot added the lib / src Issues and PRs related to general changes in the lib or src directory. label Mar 18, 2019
These tests tested internal functionality in a way that bypassed
all code that could reach these cases. Testing code like this code
to be covered even though it might actually never be reached from
anywhere if public APIs are used. It gives a false feeling of safety
that some code works as intended while there is no guarantee that
it indeed works as it should.

Therefore it seemed best to remove all of these. The only thing that
should be tested is the raw functionality of the internal errors.
This encapsulates the Node.js errors more by adding extra properties
to an error inside of the function to create the error message instead
of adding the properties at the call site. That simplifies the usage
of our errors and makes sure the expected properties are always set.
@BridgeAR
Copy link
Member Author

@@ -56,7 +57,12 @@ class SystemError extends Error {
if (context.dest !== undefined)
message += ` => ${context.dest}`;

super(message);
Copy link
Member

Choose a reason for hiding this comment

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

Why this change? I'd prefer to have it there.

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 prefer it that way as well. The problem is that you may not use this before calling super() and we need the context to be able to attach properties to the error from within the function that constructs the error message.

Copy link
Member

@mcollina mcollina left a comment

Choose a reason for hiding this comment

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

LGTM

lib/internal/errors.js Outdated Show resolved Hide resolved
@BridgeAR
Copy link
Member Author

@BridgeAR BridgeAR added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Mar 20, 2019
BridgeAR added a commit to BridgeAR/node that referenced this pull request Mar 21, 2019
These tests tested internal functionality in a way that bypassed all
code that could reach these cases. It gives a false feeling of safety
that some code works as intended while there is no guarantee that
it indeed works as it should.

Therefore it seemed best to remove all of these. The only thing that
should be tested is the raw functionality of the internal errors.

PR-URL: nodejs#26752
Reviewed-By: Matteo Collina <[email protected]>
Reviewed-By: James M Snell <[email protected]>
BridgeAR added a commit to BridgeAR/node that referenced this pull request Mar 21, 2019
This encapsulates the Node.js errors more by adding extra properties
to an error inside of the function to create the error message instead
of adding the properties at the call site. That simplifies the usage
of our errors and makes sure the expected properties are always set.

PR-URL: nodejs#26752
Reviewed-By: Matteo Collina <[email protected]>
Reviewed-By: James M Snell <[email protected]>
@BridgeAR
Copy link
Member Author

Landed in df0870d, 39f4158.

@BridgeAR BridgeAR closed this Mar 21, 2019
targos pushed a commit to targos/node that referenced this pull request Mar 27, 2019
These tests tested internal functionality in a way that bypassed all
code that could reach these cases. It gives a false feeling of safety
that some code works as intended while there is no guarantee that
it indeed works as it should.

Therefore it seemed best to remove all of these. The only thing that
should be tested is the raw functionality of the internal errors.

PR-URL: nodejs#26752
Reviewed-By: Matteo Collina <[email protected]>
Reviewed-By: James M Snell <[email protected]>
targos pushed a commit to targos/node that referenced this pull request Mar 27, 2019
This encapsulates the Node.js errors more by adding extra properties
to an error inside of the function to create the error message instead
of adding the properties at the call site. That simplifies the usage
of our errors and makes sure the expected properties are always set.

PR-URL: nodejs#26752
Reviewed-By: Matteo Collina <[email protected]>
Reviewed-By: James M Snell <[email protected]>
targos pushed a commit that referenced this pull request Mar 27, 2019
These tests tested internal functionality in a way that bypassed all
code that could reach these cases. It gives a false feeling of safety
that some code works as intended while there is no guarantee that
it indeed works as it should.

Therefore it seemed best to remove all of these. The only thing that
should be tested is the raw functionality of the internal errors.

PR-URL: #26752
Reviewed-By: Matteo Collina <[email protected]>
Reviewed-By: James M Snell <[email protected]>
targos pushed a commit that referenced this pull request Mar 27, 2019
This encapsulates the Node.js errors more by adding extra properties
to an error inside of the function to create the error message instead
of adding the properties at the call site. That simplifies the usage
of our errors and makes sure the expected properties are always set.

PR-URL: #26752
Reviewed-By: Matteo Collina <[email protected]>
Reviewed-By: James M Snell <[email protected]>
@BridgeAR BridgeAR deleted the set-properties-in-error branch January 20, 2020 11:55
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. lib / src Issues and PRs related to general changes in the lib or src directory.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants