Add flag to change catch variables' default types to unknown

[DanielRosenwasser]

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

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.

[typescript-bot]

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.

[johnnyreilly]

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 😅)

[DanielRosenwasser]

@typescript-bot pack this
@typescript-bot test this
@typescript-bot user test this
@typescript-bot run dt
@typescript-bot perf test this

[typescript-bot]

Heya @DanielRosenwasser, I've started to run the extended test suite on this PR at a32013b. You can monitor the build here.

[typescript-bot]

Heya @DanielRosenwasser, I've started to run the parallelized Definitely Typed test suite on this PR at a32013b. You can monitor the build here.

[typescript-bot]

Heya @DanielRosenwasser, I've started to run the parallelized community code test suite on this PR at a32013b. You can monitor the build here.

[typescript-bot]

Heya @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!

[typescript-bot]

Heya @DanielRosenwasser, I've started to run the tarball bundle task on this PR at a32013b. You can monitor the build here.

[typescript-bot]

Hey @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/[email protected]".;

[sandersn]

commandLineParser entry should make the new flag a strict one, I think.

[sandersn]

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.

[DanielRosenwasser]

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.

[gvanrossum]

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?)

[DanielRosenwasser]

@gvanrossum good call, thanks! Must have been an earlier copy/paste error.

[sandersn]

👍🏼 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.

[pvinis]

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.

[guilhermesimoes]

Should the flag useUnknownInCatchVariables also affect the return type of Promise.prototype.catch?

https://www.typescriptlang.org/play?strict=false&useUnknownInCatchVariables=true#code/C4JwngBA3gsAUBCB6JEB0H4F8IGMCGwuAFhABQCmIIAlNPIihAOoUTH4BubwA9hNxABLAGaQqICEIDOEfADsGyVBN6SARhRFq2AV2lD5AcynA5s3vIpolo8hKnzpwBbgq8REAKLU1dWAiIeJbSvAA21mG8RpTUaAC2FNLS+EYUNADcSljY8PAiFETEZADkJTRoBEVksSB+EAC8AHz0gUzEVGyqkjIQHhDAYAAObApg2DRAA

[DanielRosenwasser]

Should the flag useUnknownInCatchVariables also affect the return type of Promise.prototype.catch?

@guilhermesimoes #45602 proposes that idea.