-
Notifications
You must be signed in to change notification settings - Fork 10
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
refactor(errors): Node.js style validation/errors #40
Conversation
Move to Node.js style errors and validation to make it easier to drop into Node codebase. Fixes #6
errors.js
Outdated
class ERR_INVALID_ARG_TYPE extends TypeError { | ||
constructor(name, expected, actual) { | ||
super(`${name} must be ${expected} got ${actual}`); | ||
} | ||
} | ||
|
||
class ERR_NOT_IMPLEMENTED extends Error { | ||
constructor(feature) { | ||
super(`${feature} not implemented`); | ||
} | ||
} |
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.
by using native class
, this makes the package not usable in older engines, which precludes its usage by tape
.
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.
Given that the eventual target of this code is the Node.js codebase, it seems like it would be limiting to use JavaScript syntax that targets ancient engines, classes have been around since Node 6 right?
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.
Since, in the Node.js codebase, we won't pull in this errors.js
file (as it already has its own errors.js
). I don't feel super strongly about this point, I'm more concerned about us avoiding newer syntax like ?.
, ??
, etc. in the actual parser.
Perhaps open a discussion about what our engines
target should be? and we can come back and modify syntax accordingly.
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.
That’s all a fair point. Is there a need to have an error subclass tho, rather than just using an error instance with a code assigned?
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 now setting a code
, which makes the behavior of codes. SOME_ERROR
more similar to Node.js -- I'm guessing this is what's implied by Node.js placing the errors on the codes
key, that the errors created will be populated with code
equal to their class name.
I would like to continue using a class
, so that syntax used by a consumer of errors.js
is the same as in the Node.js codebase:
throw new SOME_ERROR_CODE('info')
vs.,
throw SOME_ERROR_CODE('info')
I suggest also validate But feel free to punt, I can open an issue if you prefer, one thing at a time... 😄 |
@shadowspawn I added multiples, let's wait to add |
(Marked myself as assignee to remind myself to give this a try in a program. Not claiming ownership. 😄 ) |
I'm not familiar with the node internals and more looking at the index.js end of the code, and runtime behaviour. LGTM, and runtime behaviour for an author error reasonable.
|
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.
LGTM
Move to Node.js style errors and validation to make it easier to
drop into Node codebase.
Fixes #6
Note: Like with primordials, this brings us closer to Node.js codebase's style.