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

欢迎各位小伙伴来到golang学习网，相聚于此都是缘哈哈哈！今天我给大家带来《Java异常怎么处理？记录日志还是抛出？》，这篇文章主要讲到等等知识，如果你对文章相关的知识非常感兴趣或者正在自学，都可以关注我，我会持续更新相关文章！当然，有什么建议也欢迎在评论留言提出！一起学习！

应记录可预期但不可控的外部异常（如IOException、SQLException），而非NullPointerException等逻辑错误；RuntimeException除非可恢复，否则应抛出并保留异常链；日志仅在全局处理器中记录一次，级别依业务影响而定，且需配置%ex输出堆栈。

该捕获的异常必须记录日志，不该捕获的别硬吞

Java里不是所有异常都适合记录日志。比如 NullPointerException、IllegalArgumentException 这类 RuntimeException，通常是代码逻辑缺陷导致的，上线后应暴露为错误而非静默记录——日志写了也解决不了问题，反而掩盖真实 bug。真正该记日志的是那些**可预期但不可控的外部异常**：如 IOException（文件读写失败）、SQLException（数据库连接中断）、HttpClientErrorException（第三方接口返回 4xx）等。

实操建议：

• 在 service 层或 gateway 层捕获受检异常（Exception 及其子类，但非 RuntimeException），用 log.error("msg", e) 记录完整堆栈
• 对 RuntimeException，除非你明确知道它是业务可恢复的（比如某次重试失败），否则不要 catch，让它向上抛出甚至触发全局异常处理器
• 避免在 DAO 层或工具方法里用 log.warn 吞掉 SQLException 后返回 null——调用方无法区分“查无结果”和“查崩了”

继续抛出时要保留原始异常链，别用 throw new RuntimeException(e.getMessage())

常见错误是把原始异常“降级”成新异常，丢掉堆栈和类型信息。比如这样写：throw new RuntimeException(e.getMessage())，会导致上层完全丢失出错位置、SQL 语句、HTTP 状态码等关键上下文。

正确做法是：

• 用带 cause 的构造函数： throw new ServiceException("订单创建失败", e)
• 如果只是透传，直接 throw e（针对受检异常需声明 throws）
• Spring 项目中，优先用 @ResponseStatus 或全局 @ExceptionHandler 统一处理，而不是每层都 try-catch-rethrow

日志级别不能一概而论：error 不等于“要告警”

很多团队把所有 catch 都打 error 级别，结果监控系统天天告警，最后没人看。实际上是否该告警，取决于异常发生的**业务影响面**和**可恢复性**。

判断参考：

• error：影响主流程、不可自动恢复（如支付扣款时银行接口超时且无降级）、需人工介入（如库存扣减失败导致订单状态不一致）
• warn：可降级或重试成功（如查询用户头像 CDN 失败，回退到默认头像）、不影响核心路径（如埋点上报失败）
• 绝不用 info 记录异常——它不包含堆栈，查问题时毫无价值

全局异常处理器里别再手动记录一遍日志

Spring Boot 的 @ControllerAdvice + @ExceptionHandler 是集中处理异常的好地方，但容易犯一个重复劳动的错误：在 controller 里已经 log.error 过一次，又在全局处理器里再记一次。

推荐结构：

• controller/service 层只负责「识别异常并包装业务语义」，例如：throw new OrderException("库存不足", e)
• 全局处理器统一做三件事：记录日志（仅此处记一次）、设置 HTTP 状态码、返回标准化错误体
• 确保日志格式包含 traceId、method、path、异常类名、message —— 堆栈在 log.error(msg, e) 里自然输出，不必额外 toString()

最常被忽略的一点：日志框架（如 Logback）的 %ex 模式必须显式配置，否则即使写了 log.error("", e)，控制台或文件里也看不到堆栈。

到这里，我们也就讲完了《Java异常处理：记录日志还是抛出？》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！