TS-Pattern 中如何优雅处理未匹配情况的错误

在 TypeScript 模式匹配库 TS-Pattern 中，.exhaustive() 方法是一个确保类型安全的重要工具。然而在实际开发中，所谓的"不可达代码"往往会被意外触发，特别是在处理未验证的用户输入或迁移自 JavaScript 的遗留代码库时。

现有问题分析

当前 TS-Pattern 在遇到未匹配情况时，会抛出一个普通的 Error 对象，错误信息为"Pattern matching error"。这种处理方式存在几个明显问题：

1. 错误类型识别困难：开发者难以在 catch 块中准确区分这是模式匹配错误还是其他运行时错误
2. 错误处理脆弱：依赖字符串匹配(error.message.includes)来识别错误类型是一种不稳定的做法
3. 调试信息不足：错误对象中不包含导致匹配失败的输入值，增加了调试难度

解决方案设计

为了解决这些问题，TS-Pattern 引入了专门的 ExhaustiveError 类。这个自定义错误类具有以下优势：

1. 类型安全检查：可以通过 instanceof 操作符明确识别错误类型
2. 丰富上下文：错误对象中包含导致匹配失败的原始输入值
3. 继承关系：虽然 ES5 目标下无法完全保持继承链，但仍能保持与 Error 的兼容性

实现细节

ExhaustiveError 的实现考虑了 TypeScript 的各种编译目标：

1. 对于 ES6+ 环境，完整支持自定义错误类的继承链
2. 对于 ES5 目标，虽然无法保持完整的 instanceof 关系，但仍能作为 Error 使用
3. 错误对象中包含 input 属性，方便开发者获取导致匹配失败的原始值

使用示例

try {
    const result = match(userInput)
        .with('option1', () => handleOption1())
        .with('option2', () => handleOption2())
        .exhaustive();
} catch (err) {
    if (err instanceof ExhaustiveError) {
        // 处理未匹配情况
        console.error('无效输入:', err.input);
    } else {
        // 处理其他错误
        console.error('执行错误:', err);
    }
}

最佳实践建议

1. 在关键业务逻辑中总是使用 .exhaustive() 确保所有可能性都被处理
2. 合理处理 ExhaustiveError，特别是在处理外部输入时
3. 考虑将输入验证与业务逻辑分离，提前过滤无效输入
4. 在迁移项目中，逐步引入 exhaustive 检查，而不是一次性全部添加

总结

TS-Pattern 通过引入 ExhaustiveError 显著提升了模式匹配的健壮性和可调试性。这一改进使得开发者能够更清晰地处理未匹配情况，同时为调试提供了更多上下文信息。虽然 ES5 环境下存在一些限制，但对于大多数现代 TypeScript 项目来说，这已经是一个非常有价值的增强功能。