Java异常处理：记录日志还是抛出？

一分耕耘，一分收获！既然都打开这篇《Java异常如何处理：记录日志还是继续抛出？》，就坚持看下去，学下去吧！本文主要会给大家讲到等等知识点，如果大家对本文有好的建议或者看到有不足之处，非常欢迎大家积极提出！在后续文章我会继续更新文章相关的内容，希望对大家都有所帮助！

异常该记录日志当且仅当当前层真正处理了它；若仅捕获后重抛则不应记日志，避免重复污染；已降级、兜底或告警时必须记录并标注上下文，技术异常应抛出或转业务异常，不可恢复错误不应捕获。

异常该不该记录日志，取决于它是否被当前层真正“处理”了

Java里不是所有异常都该记日志。记日志的本质是“留痕”，但只有当异常在当前方法中被决定不再向上抛、而是由本层承担后果（比如降级、重试、返回默认值）时，才需要记录——否则就是重复记录、污染日志。常见错误是：在 catch 块里只写 logger.error("出错了", e) 然后 throw new RuntimeException(e)，这等于既没处理又白记了一条。

• 如果 catch 后直接 re-throw（含包装后抛出），通常不该记日志；让最终捕获并处理它的那一层去记
• 如果 catch 后返回兜底值（如 return Collections.emptyList()）、触发告警、或做业务补偿，则必须记日志，并明确标注“已降级”“已忽略”等上下文
• 对 RuntimeException 子类（如 IllegalArgumentException），若属于调用方传参错误，通常不记 error 日志，而应记 warn 或直接抛出——避免把客户端错误当成系统故障

哪些异常适合继续抛出，哪些必须当场消化

核心判断标准是「责任边界」：当前类/模块是否拥有修复或决策能力。例如 DAO 层遇到 SQLException，它无法决定重连还是切库，只能抛出；而 Service 层收到这个异常后，可根据业务场景选择重试三次、切换读库、或返回用户“稍后再试”。

• 底层技术异常（IOException、SQLException、TimeoutException）一般要抛出或转为更语义化的业务异常（如 PaymentTimeoutException）
• 可预期的业务异常（如 InsufficientBalanceException）应定义为 unchecked 异常并抛出，由上层统一拦截返回友好提示
• 不可恢复的编程错误（NullPointerException、ArrayIndexOutOfBoundsException）不应被捕获——它们该暴露出来，而不是被吞掉或掩盖

log.error() 里传 Throwable 和不传的区别很大

很多团队用 logger.error("查询失败", e)，却没意识到如果只写 logger.error("查询失败")，堆栈就丢了。但反过来，如果在已经包装过的异常上还传原始 e，会导致重复堆栈，日志里出现两层嵌套的 cause。

• 必须传 Throwable 参数才能打印完整堆栈；只传字符串消息会丢失调试关键信息
• 如果做了异常包装（如 new ServiceException("支付失败", e)），log 时只需传新异常对象，不要额外再传原始 e
• 在异步线程或 Filter/Interceptor 中捕获异常时，注意 MDC 上下文可能未传递，需手动绑定 traceId 再记录

Spring Boot 项目里常见的异常处理陷阱

很多人依赖 @ControllerAdvice 统一处理，却忽略了它无法覆盖所有场景。比如 AOP 切面里抛出的异常、@Scheduled 方法中的未捕获异常、或者 CompletableFuture 异步回调里的异常，都不会进入全局异常处理器。

try {
    CompletableFuture.supplyAsync(() -> riskyOperation())
        .exceptionally(ex -> {
            logger.error("异步任务失败", ex); // 必须手动记日志
            return null;
        });
} catch (Exception e) {
    // 这个 catch 永远不会执行，因为 supplyAsync 是异步的
}

• @Scheduled 方法内必须自行 try-catch，否则异常会被静默吞掉
• CompletableFuture 的异常需用 exceptionally 或 handle 显式处理，不能靠外围 try-catch
• Filter 中抛出的异常若未被 Spring 的 DispatcherServlet 拦截（如发生在 doFilter chain 之前），也会绕过 @ControllerAdvice

真正难的不是语法，是每次写 catch 时想清楚：此刻我是问题的终结者，还是只是中转站。多数人错在把中转站当终点站，既记了日志又抛了异常，最后查问题时看到十条重复堆栈，却找不到真正做决策的那一行。

好了，本文到此结束，带大家了解了《Java异常处理：记录日志还是抛出？》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！