You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
refactor(errors): useTypeError for function parameters errors
[this PR is a rebase (and update) of PR #157]
For example, when constructing a new `ObjectId` object, the passed id value is validated for conversion to an hex string.
This is just fine, however a generic Error object is thrown when this validation fails.
Tracking the error then becomes unconvenient.
From official [Joyent's design patterns for errors](https://www.joyent.com/developers/node/design/errors), it is suggested that:
> 3. Use the Error's name property to distinguish errors programmatically.
> When you need to figure out what kind of error this is, use the name property.
> Built-in JavaScript names you may want to reuse include "RangeError"
> (an argument is outside of its valid range) and "TypeError" (an argument has the wrong type).
> For HTTP errors, it's common to use the RFC-given status text to name the error, like
> "BadRequestError" or "ServiceUnavailableError".
This PR uses the [`TypeError` class](https://nodejs.org/api/errors.html#errors_class_typeerror) instead of the generic `Error` object.
Because `TypeError` is a subclass of `Error`, all existing code should continue to work flawlessly and new code can more easily track an invalid argument error.
Signed-off-by: Hugo Hromic <[email protected]>
0 commit comments