java异常处理中catch块内出错会导致“二次崩溃”，应严格限定其职责为日志记录、资源清理、返回默认值等确定性操作，避免嵌入易失败逻辑；需用finally或try-with-resources替代部分清理工作，并设计全局兜底策略与可观测性机制。
当catch块里的代码也出错了，系统不会自动帮你兜底——这是Java异常处理中最容易被忽视的“二次崩溃”风险点。关键不是避免catch里出错，而是提前设计好容错路径。
明确catch块的职责边界
catch块的核心任务是“恢复现场”或“安全降级”，不是重试逻辑或复杂业务处理。把日志记录、资源清理、返回默认值这类确定性操作放在这里比较稳妥；而调用外部服务、解析新数据、更新数据库等易失败操作，应尽量移出catch块。
- ✅ 推荐：在catch中只做log.error("查询超时", e)、closeQuietly(conn)、return Collections.emptyList()
- ❌ 避免：在catch里再调用httpClient.post(...)或new ObjectMapper().readValue(...)
嵌套try-catch要克制且有层次
真需要在异常处理过程中执行可能失败的操作，可用内层try-catch隔离风险，但必须限定范围和目的。比如写日志时担心Logger本身抛NPE，可单独包一层；但不要为每个语句都加try，否则堆栈混乱、逻辑难读。
- 只对已知可能失败且后果可控的单步操作加内层捕获
- 内层catch必须有明确终点：记录警告、设标志位、或抛出更上层能理解的新异常（如new UnrecoverableStateException("cleanup failed")）
- 避免“多层空catch”——捕获后什么也不做，等于掩盖问题
用finally或try-with-resources替代部分catch逻辑
很多本该放在catch里的清理工作，其实更适合交给finally或自动资源管理。它们不依赖异常是否发生，执行更稳定，也天然规避了“catch里close又抛IOException”的陷阱。
- 文件流、数据库连接、锁等资源，优先用try-with-resources
- 需要确保执行但不依赖异常类型的通用清理（如清空ThreadLocal），放finally里
- finally中仍要避免抛出新异常——若必须报告错误，用logger.warn而非throw
定义兜底策略并暴露可观测性
当所有防御都失效（比如日志系统宕机+资源无法释放+降级数据不可用），系统至少应留下痕迹并进入预设安全态。这需要主动设计，而不是依赖JVM默认行为。
- 设置全局未捕获异常处理器（Thread.setDefaultUncaughtExceptionHandler），记录最后快照
- 关键服务配置熔断开关，在连续多次异常处理失败后自动暂停业务入口
- 所有异常处理分支都打结构化日志，包含原始异常类型、处理动作、结果状态，方便定位“哪一环崩了”
异常处理不是越深越好，而是越稳越准。真正健壮的catch，往往看起来“什么都没做”，只留痕迹、保状态、让上游决定下一步。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
