3

Closed

Typing for error object in catch statement

description

Hi, it doesn't seem to be possible to do the following:
 try {
      throw new Error("invalid foo");
 }
catch (error:Error /*Not possible*/   ) {
      error.message = "Failed op " + error.message;
      throw error;
 }
Is this by design? The only reason I can think why that may be so is that it's possible to just write throw "some error"; which would make the error object just a string. But then again shouldn't that be left to the person writing the code to decide?
Closed Feb 17 at 4:27 PM by RyanCavanaugh
'Fixed' was because we added an intelligible error message :)

This is actually by design that we don't allow it. Since we don't have any notion of what exceptions a function might throw, allowing a type annotation on 'catch' variable would be highly misleading - it's not an exception filter and it's not anything resembling a guarantee of type safety.

comments

billti wrote Mar 5, 2013 at 5:32 PM

Thanks for reporting! I'll log this for discussion, and we should be explicit in the spec and I don't see this called out, but I would speculate this might be 'by design'. By definition, an exception is an 'exceptional' condition, and could occur for a number of reason (e.g. syntax error, stack overflow, etc...). And while most of these errors do derive from the Error type, it is also possible something you call into could throw anything, e.g.
try { throw undefined; } catch(e) { console.log( typeof e ); }  // => undefined
That said, I do see typing it as Error (http://es5.github.com/#x15.11) as being the common case, what with the internal errors, and most user errors deriving from this. I see value in being able to type it as such. We'll look into it.

rb126 wrote Mar 6, 2013 at 10:12 AM

It would be cool if we could write code like this:
try {
    // processing...

    if (meltdown)
        throw new MyDerivedErrorEx("invalid foo", "my context");
}
catch (error: MyDerivedErrorEx) {
    error.message = "Failed op " + error.message + " (" + error.context + ")";
    throw error;
}
catch (error: MyDerivedError) {
    error.message = "Failed op " + error.message;
    throw error;
}
// Note that we let Error, or string, etc., propagate up to caller to handle if necessary
// because we don't know how to handle them *here*
and have it work as expected, possibly using this "catch (e if e instanceof ...)" syntax for the JavaScript:

https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Statements/try...catch

RyanCavanaugh wrote Jun 13, 2013 at 7:21 PM

Fixed in develop branch

** Closed by RyanCavanaugh 06/13/2013 11:21AM

maciejsz wrote Feb 16 at 3:02 PM

How is this fixed? I've cloned the repo, switched to devel branch and the catch (error:Error) is still showing TS1013: Catch clause parameter cannot have a type annotation..

The catch (e if e instanceof ...) is also not supported:
error TS1005: ')' expected.
error TS1005: '(' expected.
tsc --version shows Version 0.9.7.0

nabog wrote Feb 16 at 4:08 PM

@maciejsz is right: this issue has not been fixed.

Re-opening.

Ziriax wrote Jul 18 at 2:51 PM

Personally I would like to see the type of any error caught be {} instead of any...

The following code compiles without warning, but fails at runtime, even with the compiler flag --noImplicitAny
function handle(e: Error) {
    alert(e.message);
}

try {
    throw "foobar";
} catch(ex) {
    handle(ex);
}
To me, the type of ex should not be any when I provided the --noImplicitAny flag.