登录
首页 >  文章 >  java教程

Java异常处理:记录日志还是抛出?

时间:2026-02-10 20:12:58 288浏览 收藏

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

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

在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 层收到这个异常后,可根据业务场景选择重试三次、切换读库、或返回用户“稍后再试”。

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

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 的异常需用 exceptionallyhandle 显式处理,不能靠外围 try-catch
  • Filter 中抛出的异常若未被 Spring 的 DispatcherServlet 拦截(如发生在 doFilter chain 之前),也会绕过 @ControllerAdvice
真正难的不是语法,是每次写 catch 时想清楚:此刻我是问题的终结者,还是只是中转站。多数人错在把中转站当终点站,既记了日志又抛了异常,最后查问题时看到十条重复堆栈,却找不到真正做决策的那一行。

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

前往漫画官网入口并下载 ➜
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>