Promise rejection type.

[RebeccaStevens]

Search Terms

Promise Reject Type

Suggestion

Add ability to type Promise rejections.

// Current Promise Constructor Implementation:
new <T>(executor: (resolve: (value?: T | PromiseLike<T>) => void, reject: (reason?: any) => void) => void): Promise<T>;

// Proposed Change:
new <T, E = any>(executor: (resolve: (value?: T | PromiseLike<T>) => void, reject: (reason?: E) => void) => void): Promise<T, E>;

Use Cases

When handling promise rejections, the type any isn't very useful. I would be useful to have the rejection have an actual type without the need to cast or type guard.

Examples

Promise.reject<never, string>('hello world')
  .catch(reason => {
    console.error(reason.length); // `reason` is of type string.
  });

class MyError extends Error {
  // ...
}

Promise.reject<never, MyError>(new MyError(/* ... */))
  .catch(reason => {
    // `reason` is of type MyError.
    const info = reason.getMoreInfo();
    // ...
  });

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, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

[IllusionMH]

Looks like duplicate of #6283 and other similar.
See for more details #6283 (comment)

[RebeccaStevens]

I don't feel like they rejection type always has to be of type any/unknown.

It is obviously possible to detect what the rejection type is when Promise.reject is used. The hard bit would be detecting rejections caused by a throw statement inside an async function. But if we approach it from the perspective of a throw statement just being an alternative type of return statement, it seems possible to me (but maybe quite difficult).

I've been having a bit of a play with this to see what it would be like add support. This is what I've got so far just by playing with type definitions.

[IllusionMH]

p2                                         // p2 is of type Promise<number, string>
  .then((v2) =>  void cosnole.log(v2))     // v2 is of type number
  .catch((e2) => void console.error(e2));  // e2 is actually type string | ReferenceError, not string

[RebeccaStevens]

Why would the type be string | ReferenceError? Isn't TypeScript already be reporting ReferenceError when they happen (2304)? (Or is that a strict mode only thing? If so then this proposal could just be for strict mode.)

playground

[IllusionMH]

Yes, TS will report 2304 in this obvious case however emitted JS code will still have a change to receive both string and ReferenceError. Idea is to show that if there is something between resolve and catch - there are no guarantees that code between them wont throw something else (e.g. failed network request, incorrect normalize function etc.)

Looks like string will be only true for case p2.catch(...) but only if you believe that there are no other errors before resolve/reject (which might not be always true).

[RebeccaStevens]

Could you give a small example?

If myPromise.then(...).catch(...) can't be handled due to this but myPromise.catch(...) could be, imo that's still worth pursuing.

[IllusionMH]

In unsound cases or unknown external code (e.g. computedBoolean) there is always a chance to have behavior that will throw

declare const computedBoolean: (params: any) => boolean; // but in general case might throw
const list = [{id: 111}, {id: 222}];

function firstThreeIds(data: Array<{id: number}>): number[] {
    return [
      data[0].id,
      data[1].id,
      data[2].id // no compile time error, but will throw
    ];
}

const p = new Promise<number[], string>((resolve, reject) => {
  if (computedBoolean(list)) { // can throw before resolve
    resolve(firstThreeIds(list)); // wil throw before resolve
  } else {
    reject("foo");
  }
});


p
  .catch((e) => { /* ... */}); // actually string | TypeError

So it looks like closest thing e can be typed is E | Error in definition (string | Error in current example).
And again if computedBoolean won't throw anything else (not sure which case will be encountered more often).

[RebeccaStevens]

Could this proposal solve this issue?
#13219