Skip to content
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

infer err in catch(err) {} as unknown #43960

Closed
5 tasks done
gerardolima opened this issue May 5, 2021 · 7 comments
Closed
5 tasks done

infer err in catch(err) {} as unknown #43960

gerardolima opened this issue May 5, 2021 · 7 comments
Labels
Duplicate An existing issue was already created

Comments

@gerardolima
Copy link

Suggestion

I think the inferred type for err in catch (err) { } should be unknown, which it is, instead of any which is unsafe and highly discouraged. unknown is safer and provides better semantics; I really don't understand why this is not the default for tsc.

🔍 Search Terms

catch exception type inference infer unknown any

✅ Viability Checklist

My suggestion meets these guidelines:

  • This wouldn't be a breaking change in existing TypeScript/JavaScript code
  • This wouldn't change the runtime behavior of existing JavaScript code
  • This could be implemented without emitting different JS based on the types of the expressions
  • This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

Infer the type for err in catch (err) { } as unknown

📃 Motivating Example

This is valid Typescript 4.2.3 code as shown here

try { throw new Error() } catch(err) { console.log(err.potato) }

💻 Use Cases

What do you want to use this for?

Improve type safety to catch blocks.

What shortcomings exist with current approaches?

catch(err) {} infer the type of err as any

What workarounds are you using in the meantime?

catch (err: unknown) {}

@whzx5byb
Copy link

whzx5byb commented May 5, 2021

See #41016

@gerardolima
Copy link
Author

hey, @whzx5byb, #41016 advocates for a compiler flag to enable this behaviour. I advocate this to be the default behaviour. Other than that, it's the same. Should I close this issue, then?

@whzx5byb
Copy link

whzx5byb commented May 5, 2021

I think this should not be the default behavior since it would bring breaking changes.

@MartinJohns
Copy link
Contributor

MartinJohns commented May 5, 2021

@gerardolima Why do you believe changing the default type to a more restrictive one won't be a breaking change?

[x] This wouldn't be a breaking change in existing TypeScript/JavaScript code

@RyanCavanaugh RyanCavanaugh added the Duplicate An existing issue was already created label May 5, 2021
@gerardolima
Copy link
Author

hey, @MartinJohns, I think this would enforce correct type checks on optimistic code. Nevertheless, this issue was flagged as duplicate (I think related to #41016).

@Stirfry70
Copy link

Stirfry70 commented May 6, 2021 via email

@typescript-bot
Copy link
Collaborator

This issue has been marked as a 'Duplicate' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Duplicate An existing issue was already created
Projects
None yet
Development

No branches or pull requests

6 participants