-
-
Notifications
You must be signed in to change notification settings - Fork 35.4k
errors: improve ERR_INVALID_ARG_TYPE #29675
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
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
ERR_INVALID_ARG_TYPE is the most common error used throughout the code base. This improves the error message by providing more details to the user and by indicating more precisely which values are allowed ones and which ones are not. It adds the actual input to the error message in case it's a primitive. If it's a class instance, it'll print the class name instead of "object" and "falsy" or similar entries are not named "type" anymore.
- Loading branch information
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -25,7 +25,8 @@ common.expectsError( | |
| { | ||
| code: 'ERR_INVALID_ARG_TYPE', | ||
| type: TypeError, | ||
| message: 'The "url" argument must be of type string. Received type number' | ||
| message: 'The "url" argument must be of type string. Received type number' + | ||
| ' (1)' | ||
| } | ||
| ); | ||
|
|
||
|
|
@@ -34,7 +35,8 @@ common.expectsError( | |
| { | ||
| code: 'ERR_INVALID_ARG_TYPE', | ||
| type: TypeError, | ||
| message: 'The "url" argument must be of type string. Received type number' | ||
| message: 'The "url" argument must be of type string. Received type number' + | ||
| ' (1)' | ||
| } | ||
| ); | ||
|
|
||
|
|
@@ -43,8 +45,8 @@ common.expectsError( | |
| { | ||
| code: 'ERR_INVALID_ARG_TYPE', | ||
| type: TypeError, | ||
| message: 'The "job" argument must be of type ModuleJob. ' + | ||
| 'Received type string' | ||
| message: 'The "job" argument must be an instance of ModuleJob. ' + | ||
| "Received type string ('notamodulejob')" | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Micro-nit, but in messages like this one, I think it's more idiomatic for strings to be in double-quotes. Of course, both are fine in JavaScript so feel free to ignore this. People will know what is meant. (Only noticed it myself because
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I rely upon |
||
| } | ||
| ); | ||
|
|
||
|
|
@@ -53,6 +55,7 @@ common.expectsError( | |
| { | ||
| code: 'ERR_INVALID_ARG_TYPE', | ||
| type: TypeError, | ||
| message: 'The "url" argument must be of type string. Received type number' | ||
| message: 'The "url" argument must be of type string. Received type number' + | ||
| ' (1)' | ||
| } | ||
| ); | ||
Uh oh!
There was an error while loading. Please reload this page.
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.
What's the justification for changing
objecttoObject? Here are the things that come to mind as arguments against it:typeof {} === 'object'and not'Object'new Object()but you can also donew String()ornew Number()and we don't capitalize those.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.
The justification was that there are already multiple entries written as
Objectand the documentation usesObjectinstead ofobject. I personally actually favorobjecta tiny bit aboveObject. I just roughly remembered that there where comments about this in a PR quite a while ago (I do not remember which one though), so I thought I'll go for that.This actually also applies to the type
function. It is mostly written asFunction.@vsemozhetbyt I think you where involved in this discussion. Do you by any chance remember any details?
Uh oh!
There was an error while loading. Please reload this page.
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.
Sorry, I cannot remember. I can only say that we use lower case for primitives and upper case for other types in doc parts that are based on tools/doc/type-parser.js, otherwise I cannot decide what is better for code and error messages.
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.
@Trott I am fine to convert all
FunctionandObjectentries to lower cased versions, if you think that's a good way to handle it. I personally favor that.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'm fine either way.
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 might be misunderstanding you, but those seem like arguments for keeping lowercase
objecthere, because it is abouttypeofand not the prototype constructor name?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.
It's correct that we use
typeof input === 'object'in (probably) all of these cases. But when we do, we normally mean the object should haveObjectas prototype (or a null prototype as inObject.create(null)).The example above is more intuitive for me if it's written as:
The "error" argument must be of type function or an instance of Object, Error, or RegExp. That way I would immediately expect the input to be allowed to look like: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.
@addaleax what do you think would be best here? The PR should overall reduce ambiguity and seems clearer than before.
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 don’t think that’s true, and the way that JS objects work, the
Mapinstance in your example is valid because we can attach regular properties to it, too.So I’d personally stick with the current formatting of lowercase
objectunless we actually perform some kind ofinstanceof-style check.Uh oh!
There was an error while loading. Please reload this page.
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.
You are correct that it would be possible to use any object if we do the typecheck only. What we normally do is a check for a specific class, than another one and in the end we accept any object as long as it seems to fit.
However, we do mostly not accept
nulland that is also of typeobject.I decided to go for a middle ground and hope that is good for everyone: if no class is detected, we'll always use
typein combination withobject. If we detect a class andobjectas accepted values, we'll declare it asinstance of Object. This condition is pretty rare and I could only find few errors where this would apply too. That way we'll keep the distinction between different object types and usetype of objectin almost all other cases.Is that fine for you?