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
[no-throw-literal] proposal: optionally disallow throwing values of type any or unknown #4206
Comments
I take that as stating that |
A big reason it allows these unknown types is because it's very common and easy to get into these states. For example this pattern is very common: try {} catch (ex) {
// Do something first...
throw ex;
} This pattern now no longer works with the option and instead you have to add a guard and handle the non-error case. Esp for TS newbies - it is not uncommon for them to do something unsafe to shut the rule up like blindly using an function fn() {
throw 'error';
}
try {
fn();
} catch (ex) {
// Unsafe and wrong
throw ex as Error;
} I'm not against options for additional strictness here - as long as they default to allowing any/unknown. |
Yes I guess technically
Is that from the description of the build in eslint
True - its probably only useful for those who do want to add those guards and don't want to throw non
Sure - the options added in #4207 are disabled by default as you suggest. |
That's from the ts-eslint spec. https://typescript-eslint.io/rules/no-throw-literal |
Ah right - yes I updated the description in #4207 but not the title. Not sure if it's necessary or a good idea. The title is still accurate, just not a complete description of what it does (even now). |
I think this configuration goes hand in hand with |
Should this be closed now that #4207 is merged? |
Repro
Expected Result
I expect an error, because in both cases
value
does not have a type extending fromError
.Actual Result
No error
Additional Info
The docs state that the rule is called
no-throw-literal
for historical reasons (i.e. before it was aware of types). This is already an inaccurate name. I'd argue that the purpose of the rule is to prevent non-exceptions from being thrown, and therefore it should not be acceptable to throwany
orunknown
.Versions
@typescript-eslint/eslint-plugin
5.4.0
The text was updated successfully, but these errors were encountered: