Inferred promise return type is invalid when catch is not using a arrow function

[ch1ll0ut1]

TypeScript Version: 2.5.3

Code

function errorHandler(error: Error) {
  throw error;
}

function test1 () // => : Promise<string>
{
  return Promise.resolve('')
}

function test2 () // => : Promise<string>
{
  return Promise.resolve('')
    .catch((error: Error) => {
      throw error;
    });
}

function test3 () // => : Promise<string | void>
{
  return Promise.resolve('')
    .catch(errorHandler);
}
// Note: test3 as a class method has the same behavior

Expected behavior:
Functions test1 and test2 behave as exspected

Actual behavior:
The function test3 however has the return type Promise<string | void> which is not correct as functionally it has the same behavior as test2. It would never return void. As such it is a bug.

Also strange is: If i set the return type of the error handler to be of type Error. It doesnt trigger an ts error (it never returns anything). And the inferred return type of test3 is then Promise<string | Error>. The promise will never return a Error.

[aluanhaddad]

Here is a minimal repro:

const f = () => {
  throw Error();
}; // () => never
function g() {
  throw Error();
} // () => void

I do not believe this is specifically related to the declarations for Promises or even callback use.

Also strange is: If i set the return type of the error handler to be of type Error. It doesnt trigger an ts error (it never returns anything). And the inferred return type of test3 is then Promise<string | Error>. The promise will never return a Error.

That is correct behavior as a function that always throws is assignable to a function that returns a value of any arbitrary type. It is not related to the use of Error as a type annotation. If you over specify types you will get strange results.
For example, in your sample code you have

.catch((error: Error) => {
   throw error;
})

which is an incorrect annotation. It passes the typechecker because reason is any, making it assignable in both directions. There is no reason to assume that reason can be treated as an Error at runtime.

[ahejlsberg]

Duplicate of #16608.

[ch1ll0ut1]

I see the underlying problem referenced in the duplicate issue. The issue i stated here however is not about the root cause its about having to deal with promises that have additional return type because of the error handler which creates a lot of work handling the void return in every Promise.then case. I dont care about the referenced root problem. The problem here is about Promises being not usable as they should if you use normal functions. Which limits you to use arrow functions for Promise.catch. And this for me is a bug.

[mhegazy]

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