René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Allow type annotation on catch clause variable","articleBody":"**TypeScript Version:**  2.6.1\r\n\r\n```ts\r\nconst rejected = Promise.reject(new Error());\r\n\r\nasync function tryCatch() {\r\n  try {\r\n    await rejected;\r\n  } catch (err: Error) { // TS1196: Catch clause variable cannot have a type annotation\r\n    // Typo, but `err` is `any`, so it results in runtime error\r\n    console.log(err.mesage.length);\r\n  }\r\n}\r\n\r\nfunction promiseCatch() {\r\n  rejected.catch((err: Error) =\u003e { // OK\r\n    // Compiler error; Yay!\r\n    console.log(err.mesage.length);\r\n  });\r\n}\r\n```\r\n\r\nThis was discussed in #8677 and #10000. It was closed as \"fixed\" in #9999, but as far as I can tell neither of the issues was actually resolved. In either event, I'd like to make a case for allowing type annotations in catch clauses.\r\n\r\nEspecially with the introduction of downlevel async functions, I'd suggest that disallowing catch clause type annotations leads to less safe code. In the example, the two methods of handling the promise are functionally equivalent, but one allows you to type the error, and the other doesn't. Without writing _extra_ code for the `try`/`catch` version (`if (err instanceof Error) {` or `const e: Error = err` or something), you'll get a runtime error that you wouldn't get with the pure `Promise` version.\r\n\r\nThe primary rationale for not allowing this is that any object can be thrown, so it's not guaranteed to be correct. However, most of the benefit of TypeScript comes from making assertions about your and other people's code that can't be strictly guaranteed (especially when importing JavaScript). And unless one would argue that the `Promise` catch function _also_ shouldn't allow a type annotation on the error parameter, this argument seems to make very little practical sense.\r\n\r\nI believe one of the other arguments against is that it might be confusing, as it looks like the typed exception handling you might see in other languages (e.g., Java), and folks may think the catch will **only** catch errors of the annotated type. I don't personally believe that's a legitimate issue, but if it really is I'd propose at least allowing a `catch (err as Error) {` syntax or similar as a way of emphasizing that it's a type _assertion_.\r\n\r\nIf nothing else at all, it seems that there should be a way to trigger a warning (similar to an implicit any warning) when using an untyped `err` directly within a catch block.","author":{"url":"https://github.com/jaredru","@type":"Person","name":"jaredru"},"datePublished":"2017-11-15T01:00:46.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":83},"url":"https://github.com/20024/TypeScript/issues/20024"}