Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[no-object-literal-type-assertion] make allowAsParameter work with "throw" keyword? #668

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.

Sign up for GitHub

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

Jump to bottom
Closed
ZYinMD opened this issue Jul 3, 2019 · 5 comments · Fixed by #731
Closed

[no-object-literal-type-assertion] make allowAsParameter work with "throw" keyword? #668

ZYinMD opened this issue Jul 3, 2019 · 5 comments · Fixed by #731
Labels
enhancement: plugin rule option New rule option for an existing eslint-plugin rule has pr there is a PR raised to close this package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin

Comments

@ZYinMD
Copy link

ZYinMD commented Jul 3, 2019 

{
  "rules": {
    "@typescript-eslint/no-object-literal-type-assertion": ["error", {
      "allowAsParameter": true 
    }]
  }
}

My code:

else throw { code: 'E42', message: 'foo failed' } as CustomError;

Expected Result
I hope eslint would allow it, since I've set "allowAsParameter": true

Actual Result
It's not allowed, because throw is not a function, it's a function-like keyword, just like typeof or delete.

Could we make it treat throw as a function in regards to "allowAsParameter": true ?

Versions

package version
@typescript-eslint/eslint-plugin 1.9.0
@typescript-eslint/parser 1.9.0
TypeScript 3.4.5
ESLint 5.16.0
node 10.15.3
npm 6.9.0
@ZYinMD ZYinMD added package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin triage Waiting for team members to take a look labels Jul 3, 2019
@bradzacher
Copy link
Member

I don't understand - what does casting a throw do?
Are you doing it solely to make sure you adhere to a certain structure for your thrown objects?

Why not create a class, or a utility function?

@bradzacher bradzacher added awaiting response Issues waiting for a reply from the OP or another party and removed triage Waiting for team members to take a look labels Jul 3, 2019
@ZYinMD
Copy link
Author

ZYinMD commented Jul 4, 2019 •
edited
Loading

In my case, which is front-end, I want to adhere to a certain structure for the thrown objects, because all these objects with different error code will propagate to a central catch, and stored, and be displayed with an UI for the user to see.

Yes there're many ways to do it. I could also just create a typed variable and throw that variable. Maybe I fell into that mentality of "I got a cool idea so let's file an issue because why not"... Feel free to close it. :)

@bradzacher bradzacher added enhancement: plugin rule option New rule option for an existing eslint-plugin rule and removed awaiting response Issues waiting for a reply from the OP or another party labels Jul 4, 2019
@bradzacher
Copy link
Member

It wouldn't fall under the allowAsParameter option, because throw is an operator, not a function - so it's not technically a parameter.

We could always add a new option for operators.

@ZYinMD
Copy link
Author

ZYinMD commented Jul 4, 2019

One thing I've always been confused about is that return and throw are not listed on the JS Operator Precedence . Don't know if they are operators.

@bradzacher
Copy link
Member

Sorry, I wasn't intending to use the strict definition of the word operator.
It's technically not an operator, no, as operators are generally expressions.

It's a statement. Same as things like if/for/while/do...while.

Similar to those, they don't have "parameters" and are not covered by the ruke
Though the reason I say operator is because syntactically it's not much different to other operators, because it requires no parentheses and takes a single expression.

bradzacher added a commit that referenced this issue Jul 20, 2019
@bradzacher
feat(eslint-plugin): add rule consistent-type-assertions
720b624 
Merges both `no-angle-bracket-type-assertion` and `no-object-literal-type-assertion` into one rule
Fixes #332
Fixes #668
@bradzacher bradzacher mentioned this issue Jul 20, 2019
Merged
@bradzacher bradzacher added the has pr there is a PR raised to close this label Jul 20, 2019
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 21, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
enhancement: plugin rule option New rule option for an existing eslint-plugin rule has pr there is a PR raised to close this package: eslint-plugin Issues related to @typescript-eslint/eslint-plugin
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

feat(eslint-plugin)!: add rule consistent-type-assertions typescript-eslint/typescript-eslint
2 participants
@bradzacher @ZYinMD