-
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
internal/errors: improve ERR_INVALID_ARG_TYPE #13730
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.
👍 FWIW
(need 2 CTC members' approval for semver-major
s)
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.
+1 for semver-patch. IIRC the point of these new error objects is that changes in the error message can be done without semver-major because of the existence of code
.
Anyone with more experience then me, feel free to downgrade |
test/parallel/test-process-hrtime.js
Outdated
@@ -35,7 +35,7 @@ validateTuple(process.hrtime(tuple)); | |||
const invalidHrtimeArgument = common.expectsError({ | |||
code: 'ERR_INVALID_ARG_TYPE', | |||
type: TypeError, | |||
message: 'The "process.hrtime()" argument must be of type Array' | |||
message: 'The "process.hrtime()" property must be of type Array' |
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 think this is still misleading.
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.
Using the word argument
here was correct. Please wait for a decision to #13739, but this should not be changed.
Effectively blocked by #13739, see #13730 (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.
I would like to merge #13739 in about 48 hours. In order to start CI for your PR afterwards, I need you to revert your modifications to test/parallel/test-process-hrtime.js
. Take your time, there is no need to hurry (we cannot merge this before #13739 is landed and two @nodejs/ctc members still need to approve this as long as it is semver-major).
test/parallel/test-process-hrtime.js
Outdated
@@ -35,7 +35,7 @@ validateTuple(process.hrtime(tuple)); | |||
const invalidHrtimeArgument = common.expectsError({ | |||
code: 'ERR_INVALID_ARG_TYPE', | |||
type: TypeError, | |||
message: 'The "process.hrtime()" argument must be of type Array' | |||
message: 'The "process.hrtime()" property must be of type Array' |
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.
This change should be reverted, see above.
@tniessen I believe we still try to give 72 hours for review during weekends instead of the 48 hours given during the week. |
@mscdex My bad, I scheduled it for Tuesday... You are right, that's 72 hours, not 48. |
In addition to the current change I would like to also check if the provided function test (opts) {
if (!isUint8Array(opts.prop))
throw new errors.TypeError('ERR_INVALID_ARG_TYPE', 'opts.prop' ['Buffer', 'Uint8Array'], opts.prop)
}
test({ prop: [] })
// TypeError [ERR_INVALID_ARG_TYPE]: The "opts.prop" property must be instance of Buffer or Uint8Array. Received instance of Array.
// instead of
// TypeError [ERR_INVALID_ARG_TYPE]: The "opts.prop" property must be one of type Buffer or Uint8Array. Received type object
test({ prop: 'string' })
// TypeError [ERR_INVALID_ARG_TYPE]: The "opts.prop" property must be instance of Buffer or Uint8Array. Received type string.
// instead of
// TypeError [ERR_INVALID_ARG_TYPE]: The "opts.prop" property must be one of type Buffer or Uint8Array. Received type string Should I just update the PR or open another one for that? Neither the current change nor the proposed one should be semver major though as the error codes do not change and the messages are meant to change. |
This does not need to be semver-major. |
@BridgeAR I would prefer a separate PR to discuss such changes. Please rebase this on master and remove any modifications to |
Learned a new thing about error message semverity. |
The error message might be misleading if a object property was the issue and not the argument itself. Fix this by checking if a argument or a property is passed to the handler function.
5bde256
to
adc7c88
Compare
@tniessen done |
Pre land CI: https://ci.nodejs.org/job/node-test-commit/10693/ |
The error message might be misleading if an object property was the issue and not the argument itself. Fix this by checking if a argument or a property is passed to the handler function. PR-URL: nodejs#13730 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Timothy Gu <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Michael Dawson <[email protected]>
Landed in 3e17884 |
@jasnell Can you explain why it's not semver-major? |
It does not change any error types or the error code. The changes are limited to the error message and only in certain cases. Per the guidelines for the new internal/errors, changes to the message are not semver-major once the error has been migrated to use codes. |
@jasnell Why treat the error type specially (assuming you're referring to use of Also, I'm kind of surprised we're not giving any grace period for users to switch after the new errors system is rolled out (everywhere). |
I'm assuming since this changed only internal errors, and the change over to internal errors is |
@refack I don't understand what you mean by 'internal' errors. This PR changes error messages received by end users of node. |
The new errors that must include |
@refack Typically the messages aren't changed (initially) but what I said is still relevant:
|
Temporarily "don't land"ing this until |
The error message might be misleading if a object property
was the issue and not the argument itself.
Fix this by checking if a argument or a property is passed
to the handler function.
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
internal/errors