Java旧项目异常治理核心是减少无效捕获、明确异常语义、切断传播链，需分层归因、收敛处理、补全可观测性：一识别伪异常删空catch；二统一分类分层处理；三补全上下文与可观测性；四渐进式改造高频点。
Java旧项目异常多，核心不是“捕获更多”，而是“减少无效捕获、明确异常语义、切断传播链”。重点在于分层归因、收敛处理、补全可观测性。
一、识别“伪异常”：删掉无意义的 try-catch
很多老代码习惯性在每个方法里套 try-catch，但 catch 块只打印日志或吞掉异常，甚至空 catch。这类代码掩盖问题、阻碍定位、增加维护成本。
- 用 IDE 的 Inspection（如 IntelliJ 的 “Empty catch block”、“Catch Exception”）批量扫描
- 对 catch (Exception e) 或 catch (Throwable t) 的地方逐个评审：是否真需要在这里处理？能否向上抛？是否只是为“不崩”而吞异常？
- 删除空 catch；把仅 log.warn(e) + return null/0 的逻辑，改为直接抛出带业务上下文的自定义异常（如 OrderNotFoundException）
二、统一异常分类与分层处理策略
老系统常混用 RuntimeException、Checked Exception、自定义异常，且 Controller 层、Service 层、DAO 层处理方式混乱。需按职责分层收敛：
- DAO 层：只抛数据访问异常（如 SQLException → 封装为 DataAccessException），不处理业务逻辑
- Service 层：专注业务规则校验，抛业务异常（如 InsufficientBalanceException），不捕获底层异常，除非需转换语义或重试
- Controller 层：统一异常处理器（@ControllerAdvice）拦截，区分返回 JSON 错误码（4xx/5xx）、记录结构化日志、必要时触发告警
三、补全异常上下文与可观测性
老项目异常堆栈常缺关键信息：“用户ID=？”“订单号=？”“参数是啥？”，导致排查靠猜。
立即学习“Java免费学习笔记（深入）”；
- 所有自定义异常构造时强制传入 traceId、bizId（如 orderId）、关键参数（用 toString() 截断防过大）
- 日志框架（如 Logback）配置 MDC，在入口（Filter 或 WebMvcConfigurer）注入 traceId、userId、uri 等，确保每条日志自带上下文
- 关键异常（如支付失败、库存扣减失败）加独立指标埋点（如 Micrometer Counter），便于监控趋势
四、渐进式改造：从高频异常点切入
不建议全量重构。优先聚焦“报错最多、影响最大、修复最快”的模块：
- 查 ELK / Grafana 中近一周 ERROR 日志 Top 10 类型，选 2–3 个高频异常（如 “NullPointerException in OrderService.create”）专项治理
- 对每个高频异常，反向追踪：是空指针？参数校验缺失？远程调用未判空？补上 guard clause 或 Optional 处理
- 每次修复后加单元测试（覆盖该异常路径），防止回归
基本上就这些。不复杂但容易忽略——异常治理本质是“用清晰代替侥幸”，把模糊的错误流变成可读、可溯、可度量的信号流。
