v1.1.0.0 issues TS2345 if Q.Promise.then.onReject throws without a return

[psnider]

I thought that TypeScript ignores the requirement to return a value if an exception is thrown, as in the following code that compiles fine:

function n() : number {
    throw 'help';
}

But when using a Q.Promise with a specific type, not any, it seems that the compiler wants to resolve the return type of the onReject function, even though the most common usage is to throw an exception. The following code doesn't compile with tsc --module commonjs t.ts:

/// <reference path='decl/import/Q.d.ts' />
import Q                                = require('q');
interface A {a: number;}
declare function get() : Q.Promise<A>;   //  compiles if type is relaxed to any
function wrappedGet() : Q.Promise<any> {
    return get().then(
        (result) => {
            console.log('got result');
            return result;
        },
        (reason) => {
            console.log('reason=' + reason);
            throw reason;
            // return reason;    // compiles if this line is uncommented
        }
    );    
}

and issues the error:

t.ts(11,9): error TS2345: Argument of type '(reason: any) => void' is not assignable to parameter of type '(reason: any) => {}'.

Now I'm faced with adding unnecessary return statements to each of my then.onReject handlers, wherever I've tightened up the return type of the promise.

I don't think I should have to do this.
Am I doing something wrong?

For reference, a fragment of the Q declarations I'm using is:

declare module Q {
    interface IPromise<T> {
        then<U>(onFulfill: (value: T) => IPromise<U>, onReject?: (reason: any) => IPromise<U>): IPromise<U>;
        then<U>(onFulfill: (value: T) => IPromise<U>, onReject?: (reason: any) => U): IPromise<U>;
        then<U>(onFulfill: (value: T) => U, onReject?: (reason: any) => IPromise<U>): IPromise<U>;
        then<U>(onFulfill: (value: T) => U, onReject?: (reason: any) => U): IPromise<U>;
    }

    interface Promise<T> {
        then<U>(onFulfill: (value: T) => IPromise<U>, onReject?: (reason: any) => IPromise<U>, onProgress?: Function): Promise<U>;
        then<U>(onFulfill: (value: T) => IPromise<U>, onReject?: (reason: any) => U, onProgress?: Function): Promise<U>;
        then<U>(onFulfill: (value: T) => U, onReject?: (reason: any) => IPromise<U>, onProgress?: Function): Promise<U>;
        then<U>(onFulfill: (value: T) => U, onReject?: (reason: any) => U, onProgress?: Function): Promise<U>;

[psnider]

BTW, it also appears that it doesn't matter what type is returned from the onReject function.
I can only find three situations that don't compile:

• don't use a return at all
• use a return without a value
• return undefined;

everything else I've tried works fine.

[RyanCavanaugh]

The actual rule is that you do not need a return statement if the first and only statement in a function is a throw statement. The console.log call in the function expression is preventing that rule from kicking it -- if you remove it, does it compile successfully?

As a completely weird workaround you could write throw (console.log('dbg'), reason); if you still wanted the debug output.

[psnider]

I was unaware of that the throw must be the first statement. Thanks.
Perhaps it would be a useful change to accept a throw in a single execution path without requiring a return?

Also, I removed the log line, but still get the exact same error.
For reference: I modified the onReject function to be:

        (reason) => {
            throw reason;
            // return reason;    // compiles if this line is uncommented
        }

I think it's interesting, too, that the type of the return in the onReject function doesn't seem to be considered. This actually appears to be another error.

I'm not clear on the exact details of Q Promises yet, but I understand that the Promise is resolved if the onReject function returns a value. (I wrote a test program that seems to confirm this). So if this is how onReject works, this problem I'm encountering will force me to write incorrect code.

I could always modify the declarations in Q.d.ts to not specify a return value for the onReject functions, but I'd rather not do that.

[danquirk]

It does seem reasonable to consider allowing more flexibility here. It certainly wouldn't be uncommon to want to log some information before throwing. I suspect a holistic solution involves ensuring all branches of a function return an appropriate type or throw. Closing this issue as by design but can track the general suggestion for throw via #1042