关键不是让清理“一定成功”，而是确保主异常不被掩盖、清理行为可观察、系统状态不恶化：区分主次异常、清理操作单独try-catch并记录warn日志、优先使用try-with-resources、业务清理需幂等与状态检查。
编写具备容错能力的 catch 清理逻辑，关键不是让清理“一定成功”，而是确保主异常不被掩盖、清理行为可观察、系统状态不恶化。重点在于分清主次、控制影响范围、保留诊断线索。
区分主异常与清理异常，优先保障主流程可见性
当业务逻辑出错（如数据库写入失败），紧接着的清理操作（如关闭连接）又抛异常，后者属于次要问题。此时应以主异常为第一线索：
- 记录清理异常但不中断主异常传播——用日志框架输出 warn 级别信息，包含原始异常堆栈和清理上下文
- 避免在 catch 块里直接 throw 新异常覆盖原异常，除非你能明确说明二者因果关系
- 若必须合并异常，使用 initCause() 或构造函数将清理异常设为 cause，保持主异常堆栈完整
清理操作本身要加防护，不制造新故障点
清理代码（如 close()、unlock()、reset()）常因资源已释放或状态异常而失败，这类异常本就预期存在：
- 对每个清理调用单独包裹 try-catch，捕获其可能抛出的具体异常（如 IOException、IllegalStateException）
- 捕获后通常选择忽略（不 throw），但必须记录——例如 log.warn("Failed to close connection, ignored: {}", e.getMessage(), e)
- 避免在 finally 中执行可能失败的清理后再 return 或 throw，否则会吞掉 try/catch 中的异常或返回值
优先用 try-with-resources 替代手写清理
大多数资源类（InputStream、Connection、Lock）已实现 AutoCloseable，JDK 7+ 提供更安全的自动管理方式：
立即学习“Java免费学习笔记（深入）”；
- 声明资源在 try 括号内，JVM 保证无论是否异常都会调用 close()
- 若 close() 抛异常，它会被抑制（suppressed），可通过 e.getSuppressed() 获取，不影响主异常抛出
- 比手写 finally + null 判断 + 多层 try-catch 更简洁、不易遗漏、天然支持异常抑制机制
业务级清理需封装上下文，避免裸调用
非标准资源（如自定义锁、缓存标记、事务回滚标记）的清理，容易因状态不一致失败：
- 将清理逻辑封装成幂等方法——重复执行无副作用，比如 “关闭已关闭的连接” 不再抛异常
- 在清理前增加状态检查：if (resource != null && resource.isOpen()) { resource.close(); }
- 对关键业务清理（如订单取消、库存回滚），设计补偿机制而非强依赖单次清理成功
