use more specific TypeError objects for function parameters errors #157
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 can you please fix the conflicts in this PR so we can merge this? Apologies for taking so longer to get around to this. |
|
no problem @mbroadst ! |
|
@hhromic yeah I saw that issue as well and was very confused by it. We are currently in the 2.x series, and thats what you should rebase to, the 2.0.0 branch. Thanks! |
|
(closing as new PR is in place now) |
mbroadst
pushed a commit
that referenced
this pull request
Apr 16, 2018
[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]>
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.
Hi,
here is the PR for the proposed changes commented in here. I went further and modified all other functions in the codebase where this specific error object makes sense (function parameters checking). So the error handling in the lib is consistent.
Cheers and thanks!
Hugo.