错误处理检查看什么
错误处理检查的重点是失败路径：错误是否被显式处理而不是被吞掉、错误信息能否支撑排查、资源在异常路径上是否仍然释放、重试与降级是否安全。这些代码平时不执行，出问题时才暴露，因此在评审中最容易被跳过。
基本信息
| 高频问题 | 空 catch、忽略返回值、默认值掩盖失败 |
|---|---|
| 上下文要求 | 错误信息包含操作、对象标识与原始原因 |
| 资源约束 | 文件、连接、锁在异常路径同样要释放 |
| 重试要求 | 可恢复且幂等，并设置上限与退避 |
逐项看什么
- 空 catch 或忽略返回值：错误被静默吞掉，这是最常见的一类问题。
- 错误信息是否带上下文（操作、参数、对象 ID），能否用于定位。
- 资源释放：文件句柄、数据库连接、锁在异常路径上是否仍会释放。
- 重试与降级：是否幂等、有没有上限与退避、失败会不会被放大。
- 异常类型边界：可恢复错误与致命错误是否被混在一起处理。
吞错的典型形态
| 形态 | 后果 |
|---|---|
| 空 catch 块 | 故障被掩盖，排障只能靠猜 |
| catch 后只打日志继续跑 | 调用方以为成功，数据停在中间状态 |
| 忽略返回码或错误值 | 失败被当成成功，后续逻辑带着脏状态执行 |
| 默认值兜底 | 掩盖配置或网络问题，表现为难以解释的行为 |
| 捕获所有异常一把抓 | 分不出可恢复错误，重试策略失效 |
错误信息的写法
错误信息的写法
# 差：只有一句失败
log.error("查询失败");
# 好：操作 + 对象标识 + 原始原因
log.error("查询订单失败 orderId={} userId={}", orderId, userId, e);
# 边界：日志里不要带完整凭据或个人信息
# 重试：只对幂等且可恢复的失败重试，设置上限与退避重试与降级怎么看
- 只对幂等操作重试：重复提交带来的副作用往往比失败本身更麻烦。
- 重试要有上限与退避：无限重试会把下游压力放大成雪崩。
- 降级路径要明确：返回缓存、返回默认值还是直接失败，取决于业务能否接受。
- 降级要可观测：静默降级等于把问题藏起来，需要指标或日志留痕。
见到 catch 后只打日志继续跑，要追问：这里继续执行是否安全？
看错误处理时先看调用方：同一个失败在不同调用方可能需要不同处置，异常设计要能支撑这种区分。