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

Promise catch error parameter should not be of type any. #6283

Closed
tinganho opened this issue Dec 29, 2015 · 8 comments
Closed

Promise catch error parameter should not be of type any. #6283

tinganho opened this issue Dec 29, 2015 · 8 comments
Assignees
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@tinganho
Copy link
Contributor

Is there any chance, you could change the any type on error parameter on the catch method of a Promise, to a type argument instead? The type argument is provided in the Promise<R, E> type annotation, instead of just Promise<R> .

    /**
     * Sugar for promise.then(undefined, onRejected)
     *
     * @param onRejected called when/if "promise" rejects
     */
    catch<U>(onRejected?: (error: any) => U | Thenable<U>): Promise<U>;

I need to type annotate many catch method calls right now with:

.catch(error:  HTTPResponse<ErrorResponse> | Error)
@DanielRosenwasser
Copy link
Member

@rbuckton can you weigh in here?

@ivogabe
Copy link
Contributor

ivogabe commented Dec 29, 2015

I think it's not possible to type that accurately, as errors in a previous listener will be passed to the catch listener. Functions are not annotated with their possible errors, so the error could be everything, so any would be the most accurate type.

somePromise.then(x => {
  throw "foo";
}).catch(error => {
  // error can also be a string here
});

@tinganho
Copy link
Contributor Author

@ivogabe maybe it could be better handled with a union of type any?

.catch(error:  HTTPResponse<ErrorResponse> | any)

Promise rejection are not exceptions only. you consciously reject sometimes. And I just think it is a good idea that people can handle those conscious rejections, i.e. give it a type.

@tinganho
Copy link
Contributor Author

But after think about it. Maybe better to wait until default type argument lands in #2175? So that default error type is any. It also don't break anyones code then 😄 .

@zpdDG4gta8XKpMCd
Copy link

anything united with any cannot be differentiated, if it has any it will stay any

try:

function isString(value: string | any) : value is string {
    return typeof value === 'string';
}
let value : string | any;
if (isString(value)) {
    value // <-- check me
}

@tinganho
Copy link
Contributor Author

Hmm strange, typeof guards works.

let value : string | any;
if ( typeof value === 'string') {
    value // <-- check me
}

@tinganho
Copy link
Contributor Author

Just reported it here #6301.

@rbuckton rbuckton added the Working as Intended The behavior described is the intended behavior; this is not a bug label Aug 18, 2016
@rbuckton
Copy link
Member

@ivogabe is correct. The exception is typed any because we cannot guarantee the correct type of the exception at design time, and neither TypeScript nor JavaScript provide the ability to guard exception types at run time. Your best option is to use type guards to provide both a design-time and run-time check in your code.

@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug
Projects
None yet
Development

No branches or pull requests

5 participants