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

internal/errors: improve ERR_INVALID_ARG_TYPE #13730

Closed
wants to merge 1 commit into from

Conversation

BridgeAR
Copy link
Member

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), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines
Affected core subsystem(s)

internal/errors

@nodejs-github-bot nodejs-github-bot added the errors Issues and PRs related to JavaScript errors originated in Node.js core. label Jun 17, 2017
@refack refack added the semver-major PRs that contain breaking changes and should be released in the next major version. label Jun 17, 2017
Copy link
Contributor

@refack refack left a 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-majors)

Copy link
Member

@TimothyGu TimothyGu left a 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.

@refack
Copy link
Contributor

refack commented Jun 17, 2017

+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 semver level.

@@ -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'
Copy link
Member

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.

Copy link
Member

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.

@tniessen tniessen added the blocked PRs that are blocked by other issues or PRs. label Jun 17, 2017
@tniessen
Copy link
Member

Effectively blocked by #13739, see #13730 (comment)

Copy link
Member

@tniessen tniessen left a 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).

@@ -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'
Copy link
Member

@tniessen tniessen Jun 17, 2017

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.

@mscdex
Copy link
Contributor

mscdex commented Jun 17, 2017

@tniessen I believe we still try to give 72 hours for review during weekends instead of the 48 hours given during the week.

@tniessen
Copy link
Member

@mscdex My bad, I scheduled it for Tuesday... You are right, that's 72 hours, not 48.

@BridgeAR
Copy link
Member Author

In addition to the current change I would like to also check if the provided type is actually a primitive or a class (either with a whitelist of primitives or by checking if the first letter is upper case) and change the error message accordingly. If it's a class we could write instance of instead of type of and also print the provided constructor name in case the value was provided and it is of type object. The one in "one of" could also be removed if I'm not mistaken.

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.

@jasnell
Copy link
Member

jasnell commented Jun 20, 2017

This does not need to be semver-major.

@jasnell jasnell removed the semver-major PRs that contain breaking changes and should be released in the next major version. label Jun 20, 2017
@tniessen
Copy link
Member

tniessen commented Jun 20, 2017

@BridgeAR I would prefer a separate PR to discuss such changes.

Please rebase this on master and remove any modifications to test/parallel/test-process-hrtime.js (basically squash the second commit). CI won't run cleanly as it cannot automaticall merge the first commit.

@refack
Copy link
Contributor

refack commented Jun 20, 2017

Learned a new thing about error message semverity.
Ping @tniessen should this be un-blocked?

@tniessen tniessen removed the blocked PRs that are blocked by other issues or PRs. label Jun 20, 2017
@refack refack self-assigned this Jun 20, 2017
@refack refack mentioned this pull request Jun 20, 2017
3 tasks
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.
@BridgeAR
Copy link
Member Author

@tniessen done

@refack
Copy link
Contributor

refack commented Jun 20, 2017

@BridgeAR BridgeAR mentioned this pull request Jun 21, 2017
3 tasks
refack pushed a commit to refack/node that referenced this pull request Jun 22, 2017
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]>
@refack
Copy link
Contributor

refack commented Jun 22, 2017

Landed in 3e17884

@refack refack closed this Jun 22, 2017
@mscdex
Copy link
Contributor

mscdex commented Jun 22, 2017

@jasnell Can you explain why it's not semver-major?

@jasnell
Copy link
Member

jasnell commented Jun 22, 2017

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.

@mscdex
Copy link
Contributor

mscdex commented Jun 22, 2017

@jasnell Why treat the error type specially (assuming you're referring to use of Error, TypeError, RangeError, etc.) and not the message? I would think users could be explicitly checking both?

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).

@refack
Copy link
Contributor

refack commented Jun 22, 2017

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 semver-major the impact is mitigated.

@mscdex
Copy link
Contributor

mscdex commented Jun 22, 2017

I'm assuming since this changed only internal errors

@refack I don't understand what you mean by 'internal' errors. This PR changes error messages received by end users of node.

@refack
Copy link
Contributor

refack commented Jun 22, 2017

I don't understand what you mean by 'internal' errors

The new errors that must include .code as tracked by #11273. Those errors' messages were already changed in a semver-major way.

@mscdex
Copy link
Contributor

mscdex commented Jun 22, 2017

@refack Typically the messages aren't changed (initially) but what I said is still relevant:

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).

@refack
Copy link
Contributor

refack commented Jun 23, 2017

Temporarily "don't land"ing this until semverity is decided.

@targos targos added semver-major PRs that contain breaking changes and should be released in the next major version. and removed dont-land-on-v8.x labels Aug 30, 2017
@refack refack removed their assignment Oct 20, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
errors Issues and PRs related to JavaScript errors originated in Node.js core. semver-major PRs that contain breaking changes and should be released in the next major version.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants