-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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: improve the usage of TypeError[INVALID_ARG_TYPE] #16401
Conversation
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.
Some decisions probably need to be made re: functions and objects. Neither is technically a primitive.
Not sure how I feel about the need for checkExpectedTypeInitial
— feels like reviewing PRs and modifying all existing usage would take care of its purpose.
lib/internal/crypto/random.js
Outdated
@@ -16,7 +16,7 @@ function assertOffset(offset, length) { | |||
} | |||
|
|||
if (offset > kMaxUint32 || offset < 0) { | |||
throw new errors.TypeError('ERR_INVALID_ARG_TYPE', 'offset', 'uint32'); | |||
throw new errors.TypeError('ERR_INVALID_ARG_TYPE', 'offset', 'Uint32'); |
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.
Tempted to say that uint32 being lowercase was correct... here and in all other instances that aren't referring to Uint32Array.
@apapirovski Agreed. But most of the codes using |
393b85c
to
670dab3
Compare
Defensively marking as semver-major... these type of changes should only need to be semver-major while we are still in the process of converting the errors over to the new mechanism. |
👍 |
@jasnell A lot of changes here only affect the error message. If this PR can split those changes touching error codes/adding additional throws out then IMO we could land the message-only changes as semver-patch. |
@apapirovski I'd say...let's go with > util.isPrimitive(() => {})
false
> util.isPrimitive({})
false |
@joyeecheung yeah, I agree — more about whether we capitalize or not. I feel like |
lib/internal/errors.js
Outdated
'string', 'boolean', 'number', 'object', 'undefined', 'null', | ||
'object', 'symbol', 'false', 'falsy', 'function', 'uint32' | ||
]; | ||
function checkExpectedTypeInitial(expectedType) { |
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.
If this remains in some form, it should be made into a lint rule. Otherwise it should IMO be removed.
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 you split the message-only changes into separate commits? (I guess we need to split the PR as well) That way they don't have to be semver-major.
Personally I prefer not to check the capitalizations of types in runtime, we can probably just make another eslint rule for it.
lib/internal/errors.js
Outdated
} | ||
|
||
if (typeof expectedType === 'string') { | ||
const lowercase = firstLowerCase(expectedType); |
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.
Since primitiveTypes
is full of lowercase strings we can just do expectedType.toLowerCase()
lib/internal/errors.js
Outdated
|
||
if (typeof expectedType === 'string') { | ||
const lowercase = firstLowerCase(expectedType); | ||
if (primitiveTypes.indexOf(lowercase) === -1) { |
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.
primitiveTypes.includes(lowercase)
?
@joyeecheung Sorry I don't understand fully. Do you mean that split every file change (about error message) into separate commits? It will be a lot of commits I guess.
Agreed. I will remove it. |
@starkwang Sorry for not being clear enough. Some of the changes here do not add additional throw or change the error code (i.e. do not change the first argument like "ERR_*", basically they just change the capitalization, so only the errror messages are changed), those can be split into one commit, and do not have to be sermver-major(that is, can go into 8.x). Those that do change the code or add additional throws can be split into another commit and will have to wait until 9.x |
670dab3
to
c74148d
Compare
@joyeecheung I've just reduced this PR into message-only changes, which unifies the initials. |
LGTM once this changes Also I think I have incorrectly estimated the timeline in #16401 (comment) , from a quick glance I think none of the errors changed here can be backported in v8.x becuase they have not been migrated there in April anyway. The changes in this PR should be safe to land in v9.x and the other semver-major changes would probably need to wait for v10.x because we are very close to cut v9.x now. |
c74148d
to
75e6dd5
Compare
Pushed commit to address comment. |
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 odd finding. We should probably do an audit on the types passed to ERR_INVALID_ARG_TYPE
later...
@@ -1209,7 +1209,7 @@ function toUnixTimestamp(time) { | |||
} | |||
throw new errors.Error('ERR_INVALID_ARG_TYPE', | |||
'time', | |||
['Date', 'time in seconds'], | |||
['Date', 'Time in seconds'], |
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.
Not really need to be fixed in this PR, but this should be ['Date', 'string', 'number']
Personally, I usually use lowercase for things which |
75e6dd5
to
6638db6
Compare
@jasnell @joyeecheung @tniessen Is there anyone can review or land this PR? |
This is a message-only change on the migrated errors now so we don't need TSC approvals...going to land this tomorrow if no one objects. cc @nodejs/collaborators New CI: https://ci.nodejs.org/job/node-test-pull-request/11352/ |
for me, the types with actual casing that a compiler can successfully parse is one thing, and the types that a consumer can easily relate to is another thing, and it makes sense to abstract the strict syntax in human readable messages. However, consistency draws the bottom line. |
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
The initials of expected in TypeError[ERR_INVALID_ARG_TYPE] are inconsistent. This change is to unify them. PR-URL: #16401 Fixes: #16383 Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Gireesh Punathil <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>
Should this be backported to As this PR touches more than 50 files it may have been nice to get a backport lined up when this landed |
@MylesBorins This PR cannot land in v6.x or v8.x because it changes errors that have not been migrated in either branches, see #16401 (comment) . This should be possible to be backported to v9.x though, if it actually needs a backport. |
@MylesBorins Ah nevermind, I see that it's already released on v9.2.0 |
Primitives should use lowercase in error message. refs: nodejs#16401
Primitives should use lowercase in error message. Refs: nodejs#16401 PR-URL: nodejs#17568 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: James M Snell <[email protected]>
Primitives should use lowercase in error message. Refs: #16401 PR-URL: #17568 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: James M Snell <[email protected]>
Primitives should use lowercase in error message. Refs: #16401 PR-URL: #17568 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: James M Snell <[email protected]>
Primitives should use lowercase in error message. Refs: #16401 PR-URL: #17568 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: James M Snell <[email protected]>
Primitives should use lowercase in error message. Refs: #16401 PR-URL: #17568 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: James M Snell <[email protected]>
Primitives should use lowercase in error message. Refs: #16401 PR-URL: #17568 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: James M Snell <[email protected]>
Primitives should use lowercase in error message. Refs: #16401 PR-URL: #17568 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: James M Snell <[email protected]>
The initials of
expected
inTypeError[ERR_INVALID_ARG_TYPE]
are inconsistent.This PR is to:
TypeError[INVALID_ARG_TYPE]
INVALID_ARG_TYPE
Fixes: #16383
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
lib