空catch块是危险的异常吞噬行为，会掩盖问题、导致资源泄漏、状态损坏和故障难定位，必须记录日志、封装转换或分级处理，仅在极少数满足严格前提时方可忽略。
在Java中，异常绝对不可以随意忽略，尤其是用空的catch块“吞掉”异常（即不记录、不处理、不重新抛出），这是典型的异常吞噬（Exception Swallowing），会严重掩盖问题、阻碍排查、引发不可预知的运行时错误。
为什么空catch是危险的“隐形炸弹”
看似让程序“继续运行”，实则埋下隐患：
- 底层资源（如文件句柄、数据库连接、网络流）可能未被正确释放，导致内存泄漏或连接耗尽
- 业务逻辑状态已损坏（例如转账扣款成功但回滚失败），后续操作基于错误前提执行
- 线上故障无法定位——日志里没有异常痕迹，监控无告警，开发只能靠猜
- 违反“fail fast”原则：本该立即暴露的问题被延迟到更深层才崩溃，堆栈信息丢失关键上下文
哪些情况看似合理，实则仍需谨慎处理
即使你认为“这个异常肯定不影响主流程”，也应显式决策，而非静默忽略：
- “只是读配置失败，用默认值就行” → 至少记录WARN日志，说明用了默认值及原因
- “关闭流时IOException无关紧要” → 应使用try-with-resources自动管理，或至少log.debug()记录（避免干扰正常日志级别）
-
“第三方SDK抛Checked Exception但我不关心” → 显式包装为RuntimeException并带原始异常（
throw new RuntimeException("调用XX服务失败", e)），保留根源线索
安全忽略的极少数例外与前提
真正可接受“不处理”的场景极少，且必须满足全部条件：
立即学习“Java免费学习笔记（深入）”；
- 异常类型明确、语义清晰（如
NoSuchElementException在已确认集合非空的极简校验中） - 发生位置处于完全隔离、无副作用的纯计算分支（如格式化显示字段，失败则留空）
- 代码旁添加清晰注释，说明为何忽略、有何保障（例：
// 忽略：name字段允许为空，空指针仅影响展示，不影响业务逻辑） - 团队统一约定并纳入静态检查（如SonarQube规则禁止空catch，除非有指定注释标记）
推荐做法：让异常“可见、可控、可追溯”
替代空catch的务实方案：
- 记录日志：至少
logger.warn("操作X失败，跳过处理", e)，确保ERROR/WARN级别可见 - 转换封装：将Checked异常转为业务异常（
BusinessException），统一上层处理策略 - 分级响应：对可恢复异常（如网络超时）加入重试；对致命异常（如NPE、ClassCastException）直接中断并报警
- 静态检查+Code Review：用工具拦截空catch，人工审查异常处理逻辑是否符合场景语义
