errors: add ERR_INVALID_OPT_TYPE and support options in validators.js by lundibundi · Pull Request #31251

errors: add ERR_INVALID_OPT_TYPE and support options in validators.js by lundibundi · Pull Request #31251 · nodejs/node

added the errors

Issues and PRs related to JavaScript errors originated in Node.js core.

label

Jan 7, 2020

This adds `ERR_INVALID_OPT_TYPE` error that is the equivalent of
`ERR_INVALID_ARG_TYPE` for options.

`name` argument is now able to be and object with a `name` and `type`
keys. If `type` is `'option'` then `ERR_INVALID_OPT_TYPE` and
`ERR_INVALID_OPT_VALUE` errors will be used.

jasnell added the semver-major

PRs that contain breaking changes and should be released in the next major version.

label

Jan 21, 2020

lundibundi removed the semver-major

PRs that contain breaking changes and should be released in the next major version.

label

Feb 9, 2020

lundibundi added a commit to lundibundi/node that referenced this pull request

Aug 18, 2020

This will be a start to generalize all argument validation
errors. As currently we throw ARG/OPT, OUT_OF_RANGE, and other more
specific errors.
The OPT errors didn't bring much to the errors as it's just another
variant of ARG error which is sometimes more confusing (some of our code
used OPT errors to denote just argument validation errors presumably
because of similarity of OPT to 'option' and not 'options-object')
and they don't specify the name of the options object where the invalid
value is located. Much better approach would be to just specify path
to the invalid value in the name of the value as it is done in this PR
(i.e. 'options.format', 'options.publicKey.type' etc)

Also since this decreases a variety of errors we have it'd be easier to
reuse validation code across the codebase.

Refs: nodejs#31251
Refs: nodejs#34070 (comment)
Signed-off-by: Denys Otrishko <shishugi@gmail.com>

lundibundi added a commit that referenced this pull request

Sep 11, 2020

This will be a start to generalize all argument validation
errors. As currently we throw ARG/OPT, OUT_OF_RANGE, and other more
specific errors.
The OPT errors didn't bring much to the errors as it's just another
variant of ARG error which is sometimes more confusing (some of our code
used OPT errors to denote just argument validation errors presumably
because of similarity of OPT to 'option' and not 'options-object')
and they don't specify the name of the options object where the invalid
value is located. Much better approach would be to just specify path
to the invalid value in the name of the value as it is done in this PR
(i.e. 'options.format', 'options.publicKey.type' etc)

Also since this decreases a variety of errors we have it'd be easier to
reuse validation code across the codebase.

Refs: #31251
Refs: #34070 (comment)
Signed-off-by: Denys Otrishko <shishugi@gmail.com>

PR-URL: #34682
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>

joesepi pushed a commit to joesepi/node that referenced this pull request

Jan 8, 2021

This will be a start to generalize all argument validation
errors. As currently we throw ARG/OPT, OUT_OF_RANGE, and other more
specific errors.
The OPT errors didn't bring much to the errors as it's just another
variant of ARG error which is sometimes more confusing (some of our code
used OPT errors to denote just argument validation errors presumably
because of similarity of OPT to 'option' and not 'options-object')
and they don't specify the name of the options object where the invalid
value is located. Much better approach would be to just specify path
to the invalid value in the name of the value as it is done in this PR
(i.e. 'options.format', 'options.publicKey.type' etc)

Also since this decreases a variety of errors we have it'd be easier to
reuse validation code across the codebase.

Refs: nodejs#31251
Refs: nodejs#34070 (comment)
Signed-off-by: Denys Otrishko <shishugi@gmail.com>

PR-URL: nodejs#34682
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>