17370845950

捕获异常后是否继续抛出取决于当前层能否真正处理：能处理则消化（如日志、降级），不能则应二次抛出；需注意包装方式、避免重复包装、优先用受检或自定义异常；可预期分支、已补偿、仅埋点等场景宜终结异常流；吞异常仅打印stackTrace()是危险误区。

捕获异常后是否继续抛出，不能一概而论——关键看当前层是否能真正处理这个异常。能处理就消化掉（比如记录日志、降级响应、返回默认值）；不能处理或需要上层决策，就该二次抛出，把问题交给更合适的层级。

什么情况下应该二次抛出异常

以下场景建议原样或包装后重新抛出：

• 当前方法职责不包含错误恢复：比如 DAO 层查数据库失败，它只负责访问数据，不负责决定“查不到时显示什么页面”，应抛给 Service 层统一处理
• 原始异常信息对上层有意

  

  义：如 SQLException 包含具体错误码和 SQL 状态，直接包装成 RuntimeException 丢掉就丢失了诊断线索
• 需要统一异常拦截或审计：Spring 的 @ControllerAdvice 或全局过滤器依赖异常向上冒泡才能生效
• 调用方明确声明 throws：方法签名已声明抛出某异常，捕获后不做实质处理却静默吞掉，会破坏契约，调用方无法预期行为

怎么二次抛出才合理

不是简单写个 throw e; 就完事，要注意三点：

• 优先使用带 cause 的构造器包装：比如 throw new ServiceException("订单创建失败", e);，保留原始堆栈，避免“异常断层”
• 避免重复包装同一异常：不要在多层都做 new RuntimeException(e)，容易让堆栈变长且意义模糊
• 业务异常尽量用受检异常（Checked）或自定义异常类：让编译器强制调用方关注，比泛泛的 RuntimeException 更利于协作

什么情况下不该抛，而是该处理掉

以下情形适合捕获后终结异常流，不再向上扔：

• 可预期的、非错误的流程分支：比如解析 JSON 时字段缺失，业务允许为空，那就设默认值，别抛 JsonProcessingException
• 已执行有效补偿动作：如远程调用超时后自动切到本地缓存读取并返回，此时异常已完成“兜底”，无需再报
• 纯基础设施层的日志/监控埋点：例如在 Filter 中捕获异常记日志、打指标，但最终仍要 throw e; —— 这不算“处理掉”，只是增强可观测性

一个常见误区：吞掉异常还打印 stackTrace()

像这样写很危险：

看似“处理了”，实则掩盖问题：没有告警、没有监控上报、调用方收不到失败信号，系统可能持续返回错误结果而不自知。真要记录，用 SLF4J 写 log.error("xxx failed", e)，并根据业务决定是否抛出。

基本上就这些。异常不是非抛即吞的二选一，而是分层协作的信号机制——谁该看见、谁该响应、谁该兜底，得按职责划清楚。