Can't narrow error type in catch clause

[yortus]

try {
    ...
}
catch (ex) { // Adding an annotation here gives ERROR TS1196: Catch clause variable cannot have a type annotation
    if (ex instanceof FooError) {
        ex; // ex is of type any
        ex.message; // OK
        ex.iDontExist; // typechecks OK, but doesn't exist
    }
    else if (isBarError(ex)) {
        ex; // ex is of type any
        ex.foo(); // typechecks OK, but runtime error
    }
    else {
        ...
    }
}

I guess this is expected behaviour not a bug. But I was not previously aware that the catch clasue variable cannot be annotated. Due to #1426, this means we can't narrow ex inside the catch clause, so all the cases dealing with specific error types get no type checking (since ex remains as any).

[basarat]

But I was not previously aware that the catch clasue variable cannot be annotated.

The workaround is to simply create a local variable:

catch (err) {
    const ex:Error = err;

However it will not help with your desire of narrowing in any meaningful way (I think) 🌹

[yortus]

Thanks @basarat, that's what I'll do for now, and it does get narrowing working. It's a pity to need this hack though :(

[basarat]

It's a pity to need this hack though :(

Basically a throw can come from anywhere and any object can be thrown :-/ :rose:

[yortus]

Yep, that part i agree with. What bothers me is the fact that narrowing doesn't work with any, and there's no alternative to using any here.

[yortus]

@basarat BTW the hack I'm referring to is the need for both err and ex to get the job done. Someone reading this code (or, say, debugging the output js) would not understand why the second variable is required, without knowing something about the contentious history of narrowing with any.

EDIT: -And- the workaround with both err and ex is subject to the same fallacy you mention about assuming an instance of Error.

[yortus]

Isn't TS1196 an overreach by the compiler anyway? It is possible to know the range of types that can flow into a catch clause in specific code. And if TypeScript cannot infer them, then an annotation on the catch clause variable makes perfect sense (i.e. it provides information to the compiler that it cannot infer by itself, just like annotations do elsewhere). Example:

try {
    noThrow(); // This function's API docs state that it never throws an error
    foo(); // This function's API docs state that it either returns or throws a FooError
}
catch (ex: FooError) {  // ERROR TS1196
    // We could only ever get FooError here
}

[ahejlsberg]

Two interrelated issues being discussed here:

• We don't allow type annotations on catch clauses because there's really no way to know what type an exception will have. You can throw objects of any type and system generated exceptions (such as out of memory exception) can technically happen at any time. Even if we had a Java-like notion of throws annotations it is not clear that we could ever really rely on them. (And, it is also not clear that they work all that well in Java, but that's another discussion.)
• We don't narrow any in type guards unless we know the _exact_ type you're narrowing to. For example, if you check typeof x === "string" we will indeed narrow an any to string because we know for sure that is the exact type of x. That isn't the case with instanceof. Specifically, you might check x instanceof Base, but x might actually be an instance of a class derived from Base. If we narrowed x to type Base you'd see errors on access to properties of the derived class even though there is nothing wrong with the code. Now, before you argue those errors would be fine, keep in mind that the declared type of x is any, so you've already said you want no checking. We take that as an indication that we should issue errors only when we're 100% sure they're errors. And we only know that if we know the exact type.

[ahejlsberg]

Now, having said the above, we could perhaps consider allowing type annotations that specify Object or {} since every type is assignable to those types. But I don't think we could go any further than that. With an Object or {} annotation in place, instanceof type guard woulds indeed narrow the type.

[yortus]

we could perhaps consider allowing type annotations that specify Object or {} since every type is assignable to those types

👍 that would at least allow type narrowing and hence better type checking in the catch clause.

[yortus]

It would be very nice if we could type-annotate the catch clause variable with ex: Error since it's perfectly sound to do so in many if not most cases. Consider:

• System-generated exceptions (including out of memory if that indeed exists and can be caught) will always be instances of Error or one of its a subclasses such as ReferenceError.
• All other exceptions come from an explicit throw statement somewhere in our own code or in third party code, that is executed within the guarded try block.
• I control my own code so I know that it only ever throws Error instances.
• I have try blocks that contain no third party code.
• I have try blocks that reference third party libraries that very explicitly document that they only throw Error instances.

---

The counter-argument that TypeScript should disallow the annotation in all circumstances because it could be incorrect in some circumstances is an interesting one:

try {
   throw new Error("I'm an error");
}
catch (ex: Error) {  // ERROR: We won't allow this annotation even though it's valid
                     // in this case, because it might be invalid in some other case
   ...
}

...given that the obvious workaround is to exploit the "user knows best" philosophy that TypeScript applies to an equivalent annotation in a different position:

try {
   throw new Error("I'm an error");
}
catch (ex) {
    let err: Error = ex;  // OK, user knows best! And indeed in this case they are correct.
                          // But if we trust the user then why not just allow annotating `ex`?
   ...
}

[zpdDG4gta8XKpMCd]

once the exception caught what is that that you are going to do with it? a rhetorical question, but at the end of the day your options are limited:

• an unexpected exception which is absolutely nothing you can do about, extremely hard to reliably recover, takes special coding discipline to do so, just fail fast and loud
• an expected exception, with a chance for graceful recovery, if so, pardon my curiosity, why would you use exceptions (that are terribly supported by the JS runtime) if you can make it a legit part of the result value type?

function readFileSync(path: string, encoding: string): string | FileDoesNotExist | FileIsLocked {
   /* .. */
}

[yortus]

@Aleksey-Bykov you may be able to recover from some specific error type that you know may be thrown in your try block (so narrowing to that type inside a type guard would be useful), and then re-throw anything else.

[aluanhaddad]

This could lead to code that is very confusing to read.

Catch will catch everything that you might throw at it but the annotation would look like the exception type filter pattern used by many other languages.

In general those languages allow multiple catch clauses to be specified in a manner that can be seen as analogous to type pattern matching, or function overloading.

The critical difference here is that, in said languages, the behavior is generally such that if no catch clause applies to the runtime shape of the exception it is not caught at all.

Well I'm generally opposed to doing things or not doing things simply because they would be intuitive or counterintuitive to programmers coming from other languages, JavaScript explicitly supports only one catch for a reason.

Adding a type annotation would be explicitly misleading because it would intuitively suggest that the exception must be of the designated type to be caught.

However, if there is indeed a need to support different kinds of exceptions being handled differently, you could try creating a library in the vein of Scala's Try type and use user-defined type guards to match different exception types, and then possibly wrap it with a fluent API that implicitly propagates the exception when no handlers match.