| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
|
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 😅) |
Sorry, something went wrong.
|
TypeScript Bot (@typescript-bot) pack this |
Sorry, something went wrong.
|
Heya Daniel Rosenwasser (@DanielRosenwasser), I've started to run the extended test suite on this PR at a32013b. You can monitor the build here. |
Sorry, something went wrong.
|
Heya Daniel Rosenwasser (@DanielRosenwasser), I've started to run the parallelized Definitely Typed test suite on this PR at a32013b. You can monitor the build here. |
Sorry, something went wrong.
|
Heya Daniel Rosenwasser (@DanielRosenwasser), I've started to run the parallelized community code test suite on this PR at a32013b. You can monitor the build here. |
Sorry, something went wrong.
|
Heya Daniel Rosenwasser (@DanielRosenwasser), I've started to run the perf test suite on this PR at a32013b. You can monitor the build here. Update: The results are in! |
Sorry, something went wrong.
|
Heya Daniel Rosenwasser (@DanielRosenwasser), I've started to run the tarball bundle task on this PR at a32013b. You can monitor the build here. |
Sorry, something went wrong.
|
Hey Daniel Rosenwasser (@DanielRosenwasser), I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so: {
"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. There is also a playground for this build and an npm module you can use via "typescript": "npm:@typescript-deploys/pr-build@4.3.0-pr-41013-8".; |
Sorry, something went wrong.
|
Daniel Rosenwasser (@DanielRosenwasser) Comparison Report - master..41013
System
Hosts
Scenarios
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sorry, something went wrong.
There was a problem hiding this comment.
commandLineParser entry should make the new flag a strict one, I think.
Sorry, something went wrong.
| @@ -0,0 +1,35 @@ | |||
| // @useUnknownInCatchVariables: true | |||
There was a problem hiding this comment.
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.
Sorry, something went wrong.
There was a problem hiding this comment.
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.
Sorry, something went wrong.
|
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?) |
Sorry, something went wrong.
|
Guido van Rossum (@gvanrossum) good call, thanks! Must have been an earlier copy/paste error. |
Sorry, something went wrong.
There was a problem hiding this comment.
👍🏼 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.
Sorry, something went wrong.
Fixes the `no-throw-literal` rule configuration for TypeScript by enabling the appropriate rule in the TypeScript config, per [documentation](https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/no-throw-literal.md#how-to-use). This is timely due to recent [changes to TypeScript](microsoft/TypeScript#41013).
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 * 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 <bot@renovateapp.com> Co-authored-by: Amir Zarrinkafsh <nightah@me.com>
|
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. |
Sorry, something went wrong.
|
Should the flag useUnknownInCatchVariables also affect the return type of Promise.prototype.catch? |
Sorry, something went wrong.
Guilherme Simoes (@guilhermesimoes) #45602 proposes that idea. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
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.
More specifically, under this flag, the following code
would become equivalent to
As a result, a user would receive the following error message from TypeScript:
To mitigate this, a user could explicitly perform runtime checks
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.
Fixes #41016.