Different types for rejected/fulfilled Promise

[OliverJAsh]

TypeScript 1.8.9

I'm trying to understand how to correctly type a rejected promise. I expect the following code to compile.

const bar: Promise<number> =
    Promise.resolve(1)
        .then(() => Promise.reject<string>(new Error('foo')))

Error:

main.ts(7,7): error TS2322: Type 'Promise<string>' is not assignable to type 'Promise<number>'.
  Type 'string' is not assignable to type 'number'.

Is it possible to have different types for a Promise when it is rejected and fulfilled?

[yortus]

The T in Promise<T> refers to the type of the fulfilled value. There is no generic type for the rejection reason. It's type is hardcoded to any in the type definitions I've seen. E.g. here's a snippet from 'es6-promise.d.ts':

declare class Promise<T> implements Thenable<T> {
    ...
    then<U>(onFulfilled?: (value: T) => U | Thenable<U>, onRejected?: (error: any) => U | Thenable<U>): Promise<U>;
    ...

So both T and U refer to fulfillment value types, and the error reason is typed as any.

In your example, since bar has type Promise<number>, then the final promise in the chain (which is the promise assigned to bar) has to match that type. So just change the last bit to Promise.reject<number>(new Error('foo'))) and it compiles.

[OliverJAsh]

Thanks for the reply. For context I am using the built in type definitions for Promise, now provided in TypeScript itself.

In your example, since bar has type Promise, then the final promise in the chain (which is the promise assigned to bar) has to match that type.

I expected the final promise in the chain wouldn't have to match this type if it was a rejected promise.

If you take the type assertion out, it will fail:

const bar: Promise<number> =
    Promise.resolve(1)
        .then(() => Promise.reject(new Error('foo')))

Also if you throw:

const bar: Promise<number> =
    Promise.resolve(1)
        .then(() => { throw new Error('foo') })

Type 'Promise<void>' is not assignable to type 'Promise<number>'.
  Type 'void' is not assignable to type 'number'.

I can workaround it with the type assertion as you suggested, but it's not ideal.

[yortus]

The Promise<void> type comes from the type definition for Promise.reject:

reject(reason: any): Promise<void>;
reject<T>(reason: any): Promise<T>;

Your original example is using the first overload. Since there is no information available to infer the fulfillment type, it uses void. The second overload allows you to explicitly state the promise type.

Perhaps what you are wanting is for TypeScript to be able to work out that the last promise in the chain is always rejected and therefore the fulfilment value is irrelevant?

It could effectively do this if the Promise.reject type definition was changed to:

reject(reason: any): Promise<any>;

Which basically says " This will never be fulfiled so it's effectively compatible with any fulfilment value type since such a value will never be produced."

That might be a specific suggestion worth making to the team. I'm not sure if void was chosen over any for some reason overlooked here.

[avdd]

I just came across this. How should I learn the correct typings for such APIs? Just read the declaration files, or is there are more reader-friendly format published somewhere?

[mindplay-dk]

@mhegazy why was this issue closed?

I was expecting to find a generic type with two type arguments, e.g. Promise<TResolved,TRejected>.

My use-case is a simple wrapper around an XMLHttpRequest, which should resolve as a JSON object on success - on error, it should reject with the actual XMLHttpRequest instance, so the consumer can obtain the status, statusText, any returned headers, and whatever else you might need in order to handle the error.

[paldepind]

I agree with @mindplay-dk that Promises are better represented with two type arguments. There is potential for more type safety. When using then the resulting promise error type could be a union of the possible errors.

// if
fn1: (a: A) => Promise<B, Error1>
fn2: (b: B) => Promise<C, Error2>
// then
fn1(a).then(fn2): Promise<C, Error1 | Error2>

And a promise that never rejects could have the type Promise<A, never>.

[heyimalex]

Can you guarantee that a promise adheres to that signature? What if there's an unexpected exception inside your promise handler?

[kitsonk]

You can chain the promises, where the error type cannot be inferred while the resolution type can be:

function foo(result: any): number {
    if (typeof result !== 'bar') throw new TypeError('Not bar');
    return 1;
}

const result = 'foo';

const p = new Promise<string, Error>((resolve, reject) => {
    if (result === 'foo') {
        resolve(result);
    }
    else {
        reject(new Error('I wanted foo'));
    }
)
.then(foo) // return type of `foo` changes this to Promise<number, Error>
.catch((err) => {
    err; // runtime `TypeError` design time `Error` :-(
});

[mindplay-dk]

Can you guarantee that a promise adheres to that signature? What if there's an unexpected exception inside your promise handler?

Doesn't the same apply to any function?