Skip to content
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

tools: enforce throw new Error() with lint rule #3714

Closed
wants to merge 2 commits into from

Conversation

Trott
Copy link
Member

@Trott Trott commented Nov 8, 2015

@evanlucas left a comment on another PR pointing out that the convention in the code base is throw new Error() over throw Error(). This PR changes the five instances of throw Error() in the code base and enforces it with a linting rule.

@Trott Trott added the tools Issues and PRs related to the tools directory. label Nov 8, 2015

'ThrowStatement': function(node) {
if (node.argument.type === 'CallExpression') {
if (node.argument.callee.name === 'Error') {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These can be combined into a single if.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done! Thanks!

@evanlucas
Copy link
Contributor

LGTM

return {
'ThrowStatement': function(node) {
const arg = node.argument;
if ((arg.type === 'CallExpression') && (arg.callee.name === 'Error')) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small nit, but I don't think either set of internal parens are necessary.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/^[A-Z\w]*Error^/.test(arg.callee.name) should catch all other error types.

Edit: not quite. Should be: start - optional capital followed by \w* - Error - end, I think.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cjihrig I'll make that adjustment.

@Fishrock123 You're after this: /^([A-Z]\w*)?Error$/ That assumes FooError() will never be the name of a function that returns an Error object and will only be a constructor for an Error object.

@cjihrig
Copy link
Contributor

cjihrig commented Nov 8, 2015

LGTM. Is it possible to extend this rule to the other built in error types (TypeError, RangeError, etc)?

@Fishrock123
Copy link
Contributor

LGTM, we should add the other error types too though. maybe including custom errors?

@cjihrig
Copy link
Contributor

cjihrig commented Nov 8, 2015

Maybe the types that the rule applies to should be a configuration option. Then you just have to check if arg.callee.name is in an array.

@Trott
Copy link
Member Author

Trott commented Nov 8, 2015

There are only five Error types listed in the docs so we could just hard-code those, allow them to be passed as options, or go with the regular expression solution above (/^([A-Z]\w*)?Error$/). I don't have a problem with extending it this way but I also want to avoid getting mired in bikeshedding. I'm inclined to just slap in the regular expression and we can always switch to a specified list later if we want to. Thoughts?

EDIT: Actually any of the three solutions seem fine to me. I don't care, as long as there's consensus from everyone else. I think any of them will work just fine for our situation.

@cjihrig
Copy link
Contributor

cjihrig commented Nov 8, 2015

I would prefer the array config solution because then the rule can be more easily extended to things other than errors (new Socket(), new Server(), etc). I think a regex would be more limiting in that way, and, of course, less readable.

@mscdex
Copy link
Contributor

mscdex commented Nov 8, 2015

Maybe an array of strings and/or regexps? I think some simple regexps (e.g. /^(Type|Syntax|Range|Assertion|)Error$/) would be beneficial to prevent a huge list with many similar/related names.

@cjihrig
Copy link
Contributor

cjihrig commented Nov 8, 2015

@mscdex suggestion sounds like a winner to me.

@Trott
Copy link
Member Author

Trott commented Nov 9, 2015

I like the strings and regexp idea in theory, but in practice:

  • I don't think eslint can accept regular expressions as arguments. The arguments are specified in JSON Schema. No existing eslint rules accept regular expressions in the config file. The primitive types accepted are boolean, integer, number, string. I suppose we could accept strings and translate them into regular expressions, but yuck.
  • If they are all strings, it's an easy check using indexOf(). If there are regular expressions and strings mixed together, then a type check has to happen on each element. Not the end of the world, but some added complexity for functionality we may not need or use.

I'm inclined to go with an array of strings, at least initially.

@Trott
Copy link
Member Author

Trott commented Nov 9, 2015

Pushed a new commit with the "accept an array of Error types to check" feature. PTAL

@cjihrig
Copy link
Contributor

cjihrig commented Nov 9, 2015

I don't think eslint can accept regular expressions as arguments.

You're right. ESLint does the string to regex conversion instead.

module.exports.schema = {
'type': 'array',
'items': [
{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you indent this and the following two lines?

@cjihrig
Copy link
Contributor

cjihrig commented Nov 9, 2015

LGTM. I'm fine with merging the rule with its current functionality.

@jasnell
Copy link
Member

jasnell commented Nov 9, 2015

LGTM

@Trott
Copy link
Member Author

Trott commented Nov 10, 2015

@sindresorhus I proposed it but it was rejected.

I guess the next best thing would be to publish as a plugin so others can use it in their own projects. I'll get on that...

@cjihrig
Copy link
Contributor

cjihrig commented Nov 10, 2015

@Trott
Copy link
Member Author

Trott commented Nov 10, 2015

@sindresorhus A first pass is now available: https://www.npmjs.com/package/eslint-plugin-new-with-error

The documentation (and probably implementation) are lacking, but feel free to open issues left and right and that should be sufficient to shame me into improving it. :-D

In preparation for a lint rule that will enforce `throw new Error()`
over `throw Error()`, fix the handful of instances in the code that
use `throw Error()`.
Add linting rule requiring `throw new Error()` over `throw Error()`.
@Trott
Copy link
Member Author

Trott commented Nov 11, 2015

Rebased and squashed down to two commits (one for the code changes and a second for the lint rule itself). One more CI before landing: https://ci.nodejs.org/job/node-test-pull-request/698/

@jbergstroem
Copy link
Member

Never mind the ubuntu1410 slave fail. I removed it while your tests were running.

Trott added a commit to Trott/io.js that referenced this pull request Nov 11, 2015
In preparation for a lint rule that will enforce `throw new Error()`
over `throw Error()`, fix the handful of instances in the code that
use `throw Error()`.

PR-URL: nodejs#3714
Reviewed-By: Evan Lucas <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Jeremiah Senkpiel <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Trott added a commit to Trott/io.js that referenced this pull request Nov 11, 2015
Add linting rule requiring `throw new Error()` over `throw Error()`.

PR-URL: nodejs#3714
Reviewed-By: Evan Lucas <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Jeremiah Senkpiel <[email protected]>
Reviewed-By: James M Snell <[email protected]>
@Trott
Copy link
Member Author

Trott commented Nov 11, 2015

Landed in 35f2f64 and 25cd455

@Trott Trott closed this Nov 11, 2015
Trott added a commit that referenced this pull request Nov 11, 2015
In preparation for a lint rule that will enforce `throw new Error()`
over `throw Error()`, fix the handful of instances in the code that
use `throw Error()`.

PR-URL: #3714
Reviewed-By: Evan Lucas <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Jeremiah Senkpiel <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Trott added a commit that referenced this pull request Nov 11, 2015
Add linting rule requiring `throw new Error()` over `throw Error()`.

PR-URL: #3714
Reviewed-By: Evan Lucas <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Jeremiah Senkpiel <[email protected]>
Reviewed-By: James M Snell <[email protected]>
@Fishrock123 Fishrock123 mentioned this pull request Nov 11, 2015
@rvagg rvagg mentioned this pull request Dec 17, 2015
Trott added a commit that referenced this pull request Dec 29, 2015
In preparation for a lint rule that will enforce `throw new Error()`
over `throw Error()`, fix the handful of instances in the code that
use `throw Error()`.

PR-URL: #3714
Reviewed-By: Evan Lucas <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Jeremiah Senkpiel <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Trott added a commit that referenced this pull request Dec 29, 2015
Add linting rule requiring `throw new Error()` over `throw Error()`.

PR-URL: #3714
Reviewed-By: Evan Lucas <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Jeremiah Senkpiel <[email protected]>
Reviewed-By: James M Snell <[email protected]>
MylesBorins pushed a commit that referenced this pull request Jan 19, 2016
In preparation for a lint rule that will enforce `throw new Error()`
over `throw Error()`, fix the handful of instances in the code that
use `throw Error()`.

PR-URL: #3714
Reviewed-By: Evan Lucas <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Jeremiah Senkpiel <[email protected]>
Reviewed-By: James M Snell <[email protected]>
MylesBorins pushed a commit that referenced this pull request Jan 19, 2016
Add linting rule requiring `throw new Error()` over `throw Error()`.

PR-URL: #3714
Reviewed-By: Evan Lucas <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Jeremiah Senkpiel <[email protected]>
Reviewed-By: James M Snell <[email protected]>
@MylesBorins MylesBorins mentioned this pull request Jan 19, 2016
@Trott Trott deleted the new-error branch January 13, 2022 22:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
tools Issues and PRs related to the tools directory.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants