TypeScript ESLint 规则优化：安全处理错误重抛机制

在 TypeScript 项目中，错误处理是一个需要特别注意的环节。typescript-eslint 项目中的 only-throw-error 规则旨在确保开发者只抛出 Error 类型的对象，而不是任意值。这一规则对于提高代码质量和可维护性非常重要，但在实际应用中，它可能会与一些常见的错误处理模式产生冲突。

规则背景与现状

only-throw-error 规则的基本理念很简单：强制开发者只能抛出 Error 类型或其子类的实例。这样做有几个好处：

1. 确保错误对象具有标准的堆栈跟踪信息
2. 保持错误处理的一致性
3. 避免抛出原始值（如字符串或数字）导致的问题

当前规则提供了 allowThrowingAny 和 allowThrowingUnknown 两个选项，允许开发者放宽对 any 和 unknown 类型的限制。然而，这些选项过于宽泛，可能导致潜在的安全问题。

实际问题分析

在错误处理中，一个常见的模式是捕获错误后，进行部分处理（如日志记录），然后重新抛出原始错误。这种情况下，TypeScript 会将捕获的错误变量类型推断为 unknown：

try {
  // 可能抛出错误的操作
} catch (error) {
  console.error('操作失败');
  throw error; // 这里会被 only-throw-error 规则标记
}

当前解决方案要么是使用 allowThrowingUnknown 选项（过于宽松），要么是添加类型检查（增加冗余代码）：

try {
  // 可能抛出错误的操作
} catch (error) {
  console.error('操作失败');
  if (error instanceof Error) {
    throw error;
  }
  throw new Error('操作失败', { cause: error });
}

技术讨论与解决方案

经过深入讨论，社区提出了一个更精细的解决方案：增加一个专门针对错误重抛场景的选项。这个方案有以下特点：

1. 只允许在 catch 块中直接重抛捕获的错误
2. 不允许随意抛出 unknown 类型的其他值
3. 保持对错误创建时的严格类型检查

这种方案平衡了类型安全性和开发便利性。它识别了错误传播（propagating）和错误创建（creating）之间的本质区别：

• 错误创建：开发者有完全控制权，应该严格限制为 Error 类型
• 错误传播：可能是第三方代码抛出的，开发者只能原样传递

实现建议与最佳实践

对于规则的使用者，建议采用以下最佳实践：

1. 对于新项目，启用这个新选项（预计会作为默认配置）
2. 对于现有项目，可以逐步迁移到更严格的错误处理模式
3. 在必须处理未知错误类型时，考虑使用 Error 包装模式

对于规则维护者，需要注意：

1. 实现时要精确识别 catch 块中的重抛场景
2. 文档中要明确说明选项的适用范围和限制
3. 考虑与 prefer-promise-reject-errors 规则的协同工作

总结

TypeScript ESLint 的 only-throw-error 规则通过这次优化，更好地适应了实际开发中的错误处理模式。这种精细化的规则调整体现了静态类型检查与开发实践之间的平衡艺术，既保持了类型系统的严谨性，又不失开发的人性化考量。

对于 TypeScript 开发者来说，理解并正确应用这些规则，可以显著提高错误处理的代码质量，同时避免过度工程化带来的负担。这种平衡正是 TypeScript 生态系统成熟度的重要体现。