Error.name should not contain display elements
- Version: 10.0.0-pre (master)
- Platform: n/a
- Subsystem: error
Remainder of this is a comment by @felixfbecker
in https://github.com/nodejs/node/issues/13937#issuecomment-384019066 that I think deserves its own issue:
I agree that adding the code to the name
is weird. For me name
is a programmatically-inspectable property, just like code
, and not for "human consumption" like message
. Having pretty formatting in there with a space and brackets goes against that.
Browser errors have no code
property, they always use name
, so that's where this intuition is coming from. For example, for fetch
you would have to check if err.name === 'AbortError'
. The only other option is using instanceof
, but that is bad practice (assert on interfaces, not implementations).
Personally I see code
as a subcategory of name
, e.g. name
can be TypeError
and code
ERR_SOCKET_BAD_TYPE
. It's both useful to be able to make assertions about the broader category of and error as well as the exact error reason. For example, in an Express error handler, I might want to never return any TypeError
s to the client because they are programming errors. Or take p-retry as an example (emphasis mine):
Returns a Promise that is fulfilled when calling input returns a fulfilled promise. If calling input returns a rejected promise, input is called again until the max retries are reached, it then rejects with the last rejection reason. It doesn't retry on TypeError as that's a user error.
Checking code
here wouldn't be helpful.
I would prefer if both name
and code
are for programmatic inspection without fancy formatting, and Error.prototype.toString()
could be modified to include both error.name
and error.code
in the output, as toString()
is unarguably purely for human consumption. Doing this for all errors, including user errors, would be a great feature and encourage users to make use of error codes too. Alternatively it could only be an internal base error class.