TypeScript为何不提供强类型try-catch语句？

假设的TypeScript类型化catch代码： #

try {
  ...
} catch (e: MyError) {
  ...
} catch (e: string) {
  ...
}

等价的JavaScript编译产物： #

try {
  ...
} catch (e) {
  if (e instanceof MyError) {
    ...
  } else if (typeof e === 'string') {
    ...
  } else {
    throw e;
  }
}

1. TypeScript是否考量过该特性？ #

TypeScript团队确实多次讨论过类型化catch分支的特性，早在TypeScript 4.0前后就有相关的提案草稿和设计讨论。这个特性的核心优势和你提到的一致：能更清晰地表达异常处理范围，同时自动转发未匹配的异常，代码意图更简洁。

但最终没有落地，核心考量包括：

• 运行时行为一致性：JavaScript原生catch不区分异常类型，所有异常都会被单个catch捕获。新增类型化catch会让TypeScript语法和原生JS的行为逻辑产生明显差异，可能让开发者误解这是JS原生支持的特性。
• 类型检查复杂度：比如处理类型重叠（如自定义Error及其子类）的优先级、非Error类型异常（字符串、数字等）在不同环境下的一致性，都是需要解决的细节问题。
• 社区反馈平衡：部分开发者希望更严格的类型约束，但也有开发者担心过度偏离JS原生语法，增加学习和迁移成本。

2. 编译为等价JS是否存在语法不合理性？ #

从技术实现上，把类型化catch编译成if-else条件判断的方案是可行的，但确实存在几个争议点：

• 语义匹配问题：原生JS的catch子句语义是“捕获所有异常”，而类型化catch在语法层面新增了“分支捕获”的语义，这属于对原生语法语义的扩展，可能让不熟悉编译逻辑的开发者混淆。
• 隐含行为的风险：等价代码里默认转发未匹配异常的行为是隐含的，而原生JS如果不手动throw会吞掉异常。如果开发者忽略这个隐含逻辑，可能会在调试时遇到困惑。
• 边缘场景的兼容性：比如对于null、undefined或者自定义非Error类型的异常，instanceof和typeof的判断逻辑是否能完全覆盖开发者的预期，存在不确定性。

内容的提问来源于stack exchange，提问作者Irfy