We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
There was an error while loading. Please reload this page.
catch
unknown
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
This change adds a new flag called useUnknownInCatchVariables which changes the default type of catch clause variables from any (today's existing behavior) to unknown.
useUnknownInCatchVariables
any
More specifically, under this flag, the following code
try { / ... } catch (err) { console.log(err.message); }
would become equivalent to
try { / ... } catch (err: unknown) { console.log(err.message); / error: Property 'message' does not exist on type 'unknown'. }
As a result, a user would receive the following error message from TypeScript:
Property 'message' does not exist on type 'unknown'.
To mitigate this, a user could explicitly perform runtime checks
try { / ... } catch (err) { / First check if we have an Error if (err instanceof Error) { console.log(err.message); } }
or if that is too painful, a user could use a type assertion to any, or provide an explicit annotation on the catch clause variable with the type any to revert to the old default behavior.
try { / ... } catch (err: any) { console.log(err.message); }
Fixes #41016.
Sorry, something went wrong.
87b36c9
bbb3bfb
cccf22a
The TypeScript team hasn't accepted the linked issue #41016. If you can get it accepted, this PR will have a better chance of being reviewed.
It would be awesome if strict also enabled this flag; is that likely? (It's possible that this change does that already; but I'm on my phone so it's hard to tell 😅)
strict
Add test case for 'useUnknownInCatchVariables'.
ac4490c
Add new 'useUnknownInCatchVariables' flag.
07a9e49
Accepted baselines.
4f0baa0
Add test for catch variable explicitly typed as 'any'.
cc6e761
cd08b62
Move option under 'strict'.
f529457
7c01840
a32013b
@typescript-bot pack this @typescript-bot test this @typescript-bot user test this @typescript-bot run dt @typescript-bot perf test this
Heya here.
Update: The results are in!
Hey an installable tgz. You can install it for testing by referencing it in your package.json like so:
package.json
{ "devDependencies": { "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/102337/artifacts?artifactName=tgz&fileId=CB39C963580F3F2B857D3171C4A6770212DE0222B86B618B209B2F4B2E12A36B02&fileName=/typescript-4.3.0-insiders.20210505.tgz" } }
and then running npm install.
npm install
There is also a playground npm module you can use via "typescript": "npm:@typescript-deploys/[email protected]".;
"typescript": "npm:@typescript-deploys/[email protected]"
@DanielRosenwasser The results of the perf run you requested are in!
Comparison Report - master..41013
Download Benchmark
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
commandLineParser entry should make the new flag a strict one, I think.
except for this, I'm not convinced we even need a new test, since we know that unknown narrows, and from some other tests, that strict changes the type of the catch variable to unknown.
I guess there's nothing to change here, except possibly dropping the narrowing tests from this test.
I added that style of code in because most of the purpose of this feature is to ensure that catch variables are narrowed, and that we error on usages if a user doesn't do so.
Meta: I was confused by the initial comment, because I wasn't familiar with unknown. I'd say that the first snippet, with catch (err) should not have a comment indicating the error (because IIUC without the new flag it doesn't produce an error), and the second snippet, with explicit catch (err: unknown) should have the error comment, because even without the new flag that's an error. (Right?)
catch (err)
catch (err: unknown)
@gvanrossum good call, thanks! Must have been an earlier copy/paste error.
'useUnknownInCatchVariables' is strict in command line help.
0ea20ff
👍🏼 Does what we talked about in the design meeting.
Side note: It's a little worrying that we don't already have more tests with both (1) catch and (2) strict: true.
strict: true
Merge remote-tracking branch 'origin/main' into unknownInCatchVariables
49e652d
9906092
#201)
278b245
Fixes the `no-throw-literal` rule configuration for TypeScript by enabling the appropriate rule in the TypeScript config, per [documentation](microsoft/TypeScript#41013).
fix(web): cast try catch err type to error
29bd07b
Typescript 4.x changes the default behaviour of try catch and its err type from `any` to [`unknown`](microsoft/TypeScript#41013). This change ensures that where we rely on said variable it is cast accordingly as an `Error`.
build(deps): update dependency typescript to v4.4.2 (#2321)
5f2edf3
* build(deps): update dependency typescript to v4.4.2 * fix(web): cast try catch err type to error Typescript 4.x changes the default behaviour of try catch and its err type from `any` to [`unknown`](microsoft/TypeScript#41013). This change ensures that where we rely on said variable it is cast accordingly as an `Error`. Co-authored-by: Renovate Bot <[email protected]> Co-authored-by: Amir Zarrinkafsh <[email protected]>
Is there a way to type a function that it throws specific types? So that catch could know what to expect.
Like a func that can throw MyError, and then catch knows that e is MyError.
MyError
e
Should the flag useUnknownInCatchVariables also affect the return type of Promise.prototype.catch?
Promise.prototype.catch
https://www.typescriptlang.org/play?strict=false&useUnknownInCatchVariables=true#code/C4JwngBA3gsAUBCB6JEB0H4F8IGMCGwuAFhABQCmIIAlNPIihAOoUTH4BubwA9hNxABLAGaQqICEIDOEfADsGyVBN6SARhRFq2AV2lD5AcynA5s3vIpolo8hKnzpwBbgq8REAKLU1dWAiIeJbSvAA21mG8RpTUaAC2FNLS+EYUNADcSljY8PAiFETEZADkJTRoBEVksSB+EAC8AHz0gUzEVGyqkjIQHhDAYAAObApg2DRAA
#45602 proposes that idea.
no-implicit-any-catch
sandersn sandersn approved these changes
andrewbranch Awaiting requested review from andrewbranch
RyanCavanaugh Awaiting requested review from RyanCavanaugh
weswigham Awaiting requested review from weswigham
ahejlsberg Awaiting requested review from ahejlsberg
DanielRosenwasser
Successfully merging this pull request may close these issues.