异常处理中如何记录日志后继续向上层传递异常

异常处理中的“重抛”技巧：利用 throw e 在记录日志后继续向上层交付异常变量的处理权

在Java异常处理流程中，重抛异常的核心目标非常明确：允许当前代码层执行必要的干预操作，例如记录关键日志或清理临时资源，然后将异常“完整无损”地传递给上层调用方进行最终处理。这里的核心在于“完整无损”——必须确保异常的原始类型、完整的堆栈轨迹以及因果链（cause chain）得到保留。一旦这些关键信息被破坏，上层系统将难以准确定位和诊断问题根源，导致调试过程变得异常复杂和低效。

为什么必须用 throw e，而不是 throw new RuntimeException(e)

这两种写法虽然都抛出异常，但其效果截然不同。直接使用 throw e; 是将捕获到的原始异常对象原样向上传递；而 throw new RuntimeException(e); 则是创建了一个全新的RuntimeException实例，并将原异常作为其cause。关键问题在于：新异常的堆栈轨迹会从包装代码行开始记录，原始的出错堆栈被截断并隐藏在cause中。这在排查分布式调用链路或复杂的异步任务故障时，会严重阻碍问题定位，导致排查效率大幅降低。

• 正确写法：throw e; —— 堆栈信息清晰指向最初抛出异常的位置。
• 错误写法：throw new RuntimeException(e); —— 堆栈信息从包装处重置，原始调用链路丢失。
• 折中方案：如果确实需要包装，应考虑继承原始异常类型，或者确保新异常的构造函数将 e 作为cause传入，以保留线索。

日志记录后重抛的典型场景

并非所有异常都需要在当前层被“吞掉”或完全处理。一个典型的应用场景是数据库操作失败：开发者可能希望在DAO层记录下出错的SQL语句和参数详情，便于事后审计与分析，但具体的重试策略或业务降级逻辑，则应交由更上层的服务或统一的全局异常处理器来统一决策与兜底。

• 标准操作是：先 log.error(“DB execute failed, sql: {}, params: {}”, sql, params, e); 记录下关键上下文。
• 紧接着，毫不犹豫地执行 throw e;，不要在中间添加额外的判断或延迟。
• 这里有个常见的陷阱：避免在 finally 代码块中抛出异常，因为它可能会覆盖掉 try/catch 块中已经抛出的原始异常，导致真正的根因丢失。

检查型异常重抛需注意方法签名

在Java中处理检查型异常（Checked Exception）时，重抛会多一层语法约束。如果你捕获的是像 IOException 或 SQLException 这类检查型异常，而当前方法声明中并没有包含相应的 throws 子句，那么直接 throw e; 会导致编译失败。

• 方案一（推荐）：在方法签名中补上相应的 throws 声明，让异常沿着调用链自然传播。
• 方案二：将其转换为非检查型异常（Unchecked Exception），例如使用JDK 7+提供的 throw new UncheckedIOException(e);。
• 不推荐的做法：简单地包装成 RuntimeException，除非团队有明确的约定，并且能接受由此带来的调试线索弱化的代价。

重抛时要不要调用 fillInStackTrace()？

答案是：绝大多数情况下，不要调用。这个方法的作用是重新填充堆栈轨迹，将当前的抛出点设置为堆栈的起点。它仅适用于一些特殊的封装场景，例如你想隐藏异常在中间层的传播路径。但对于日常“记录日志后重抛”的需求，调用它只会让堆栈信息失真，反而不利于问题回溯与根因分析。

• 默认的 throw e; 会保留最完整的原始堆栈，这是最安全、最推荐的做法。
• e.fillInStackTrace() 是主动重置堆栈，仅在深度封装异常、并有意掩盖内部传播细节时才需要考虑。
• 需要警惕的是，许多现代的监控系统和日志分析平台都依赖异常的原始堆栈信息进行错误聚合和告警，随意重置会严重影响问题的归因分析。