use the more specific TypeError objects for function parameters errors.
#243
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@hhromic hi, sorry one last thing, please don't commit the update to the browser build. That will be updated automatically as part of the build process. Thanks! |
|
Hi, thanks for the clarification! Indeed I was confused if I should have updated the browser build or not. |
…ors. [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]>
|
@hhromic thanks for the contribution! |
|
happy to help! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
[this PR is a rebase (and update) of PR #157]
When constructing a new
ObjectIdobject, 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, it is suggested that:
This PR uses the
TypeErrorclass instead of the genericErrorobject.Because
TypeErroris a subclass ofError, all existing code should continue to work flawlessly and new code can more easily track an invalid argument error.