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

Suggestion: stricter type for promise rejection value/reason #17440

Closed
OliverJAsh opened this issue Jul 26, 2017 · 4 comments
Closed

Suggestion: stricter type for promise rejection value/reason #17440

OliverJAsh opened this issue Jul 26, 2017 · 4 comments
Labels
Declined The issue was declined as something which matches the TypeScript vision

Comments

@OliverJAsh
Copy link
Contributor

TypeScript Version: 2.4.1

Code

promise.catch(error => {
  error.foo.bar // no error. `error` type is `any`
})

In this example, there is no type checking on property lookups on error because error has type any.

I understand it is not possible to know the true type of a the rejected promise value/reason (see #5413). However, I would question whether we could replace any with the empty object type {}.

This would mean the above example would throw a type error, which is desirable because it is safer. The user may widen choose the type of error using user-defined type guards.

Has this been considered at all? I am also curious if the same idea could be applied to other uses of any in libs.

@yortus
Copy link
Contributor

yortus commented Jul 27, 2017

This has definitely been brought up before (eg here and here in more detail here).

As you say, any in .d.ts files makes consuming code less type safe by silently disabling type-checking in parts of your code, such as in your example with promise.catch.

A suggested solution that I quite like has been made in #10715.

However, updating all the any annotations in lib files to {} or unknown would be a breaking change.

@benjamingr
Copy link

@yortus I think TypeScript should just set the reason parameter to Error rather than any because rejecting with anything but an error likely doesn't give you a stack trace.

@mhegazy mhegazy added the Needs Investigation This issue needs a team member to investigate its status. label Aug 29, 2017
@mhegazy mhegazy added Declined The issue was declined as something which matches the TypeScript vision and removed Needs Investigation This issue needs a team member to investigate its status. labels Feb 12, 2018
@mhegazy
Copy link
Contributor

mhegazy commented Feb 12, 2018

I do not think we will be open to taking such a breaking change in the standard library. a local change to the Promise definition should achieve the desired outcome.

@typescript-bot
Copy link
Collaborator

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Declined The issue was declined as something which matches the TypeScript vision
Projects
None yet
Development

No branches or pull requests

5 participants