Repository navigation
Flag to type 'catch' variables as 'unknown'. #41016
Description
In TypeScript 4.0, we allowed users to to annotate catch variables with : unknown; however, it'd be nice if we could have that be the default.
I could imagine a flag like --useUnknownInCatchVariables to switch the default type to be unknown.
// @useUnknownInCatchVariables: true
try {
// ...
}
catch (e) {
e.toUpperCase(); // error
}Alternatively, I could also imagine a much broader flag that also types parameters as unknown as well.
Activity
MartinJohns commentedon Oct 9, 2020
Daniel Rosenwasser (@DanielRosenwasser) You might want to proofread the title.
DanielRosenwasser commentedon Oct 9, 2020
GitHub seems to be having UI glitches for me or something....
[-]Flag to tur[/-][+]Flag to type 'catch' variables as 'unknown'.[/+]AviVahl commentedon Oct 10, 2020
Default in tsc --init please? :)
treybrisbane commentedon Oct 10, 2020
Daniel Rosenwasser (@DanielRosenwasser) will this flag be included in
strict?gerardolima commentedon May 5, 2021
I believe this should be the default behavior, actually. The inferred type for
errincatch (err) { }should beunknown, which it is, instead ofanywhich is unsafe and highly discouraged.unknownis safer and provides better semantics; I really don't understand why this is not the default for tsc.MartinJohns commentedon May 5, 2021
Gerardo Lima (@gerardolima) TypeScript usually does not introduce breaking changes without a very good reason, which I'd argue this is not. It's in the same realm with the strict compiler flags, which all are breaking changes and are opt-in.
gerardolima commentedon May 5, 2021
Only code that rely on wrong assumptions (and
any) would brake, Martin Johns (@MartinJohns). As extensively demonstrated, exceptions in JS can be just anything and that's why no assumption should be valid on their types by default. This semantic is aligned with the TS typeunknown, instead ofany. Obviously, this is my view on the subject and that may not be aligned with TS team.DanielRosenwasser commentedon May 5, 2021
So through a personal Twitter survey, current results show that many people have voted for
unknownas their preference incatchclause variables. There's definitely a bias there, but the preference betweenanyandunknownskews higher towardsunknownthan I would've expected.That said, there are two things worth mentioning:
unknownincatchvariables.Erroror some form of checked exceptions, which is not necessarily at odds with this, but worth considering in case this conflicts with future work.samhh commentedon May 6, 2021
I suspect you could broadly split TypeScript devs into two camps, those who're migrating from JavaScript or otherwise just want a barely-typed experience, and those who want their type system to be as safe as possible thus want to avoid
any. For example, I'd be surprised if anyone wantedunknowncatch clause variables but didn't also wantJSON.parseto returnunknown.Totally anecdotal, but in codebases I've worked on where we've made use of try/catch for control flow we seldom ever treated it as anything other than
unknown, it was generally just a value to propagate, be that to the console, an external logging service, etc. Even with a flag like this enabled the exceptions to the rule could easily be overridden with assertions.ritschwumm commentedon May 6, 2021
i suspect the camp migrating from javascript is on the decline - at least in my experience nobody starts a project in plain JS any more when it's possible to use TS instead. and - having just migrated a medium-sized project from JS to TS - i'd still be glad for any help the typechecker can give me to make things right while i'm at it. even if it takes a bit more effort.
MartinJohns commentedon May 6, 2021
ritschwumm There are many projects out there that don't support strict type checks, and new ones are still created each day. Two examples I recently had to suffer from are Angular (which just recently started supporting
strictNullChecks(released Sep 2016), disabled by default) and NestJS (which does not support strict type checks).So I wouldn't say the only issue are projects migrating from JS.
gerardolima commentedon May 6, 2021
Sam A. Horvath-Hunt (@samhh) the following code fails with typescript-eslint (@typescript-eslint) rules due to no-unsafe-assignment; that's what I want to avoid. Variables typed as
anyare obviously handy, but they are unsafe and removing that liability is the whole point of TypeScript. So, in my opinion, the behaviour that infers types asanyshould be the optional ones.phiresky commentedon May 8, 2021
Just want to mention there's a typescript-eslint rule to disallow inferring of the catch type (to enforce using
catch(err: unknown)): no-implicit-any-catch.Would be great to have it integrated in typescript though.