空 catch 块会静默丢弃异常，掩盖问题导致故障难定位、数据不一致及调试成本剧增；应按需记录日志后抛出、转为业务异常或仅在有明确兜底时捕获，禁用无处理的空 catch。
空 catch 块（即 catch (Exception e) { } 这类不作任何处理的捕获）在 Java 中看似“让程序不崩溃”，实则埋下严重隐患：它会静默丢弃异常信息，掩盖真实问题，导致故障难以定位、逻辑错误持续发生，甚至引发数据不一致或安全漏洞。
空 catch 导致问题无法发现
异常是程序运行中发出的明确信号，比如文件不存在、网络超时、类型转换失败。一旦被空 catch 吞掉，调用方完全感知不到失败，后续代码可能基于错误前提继续执行。
- 例如：读取配置文件失败后未加载默认值，却继续用 null 配置初始化服务 → 启动后功能部分失效，日志里却一片平静
- 再如：数据库插入因唯一约束失败被吞掉，用户重复注册无提示，后台却已产生脏数据
调试成本剧增，线上问题“查无此异常”
没有堆栈、没有日志、没有告警，开发和运维只能靠“现象反推”。一个本可在 5 分钟内通过异常堆栈定位的空指针，可能演变成连续两天的灰度排查、回滚、加监控、再复现的循环。
- JVM 不会记录被吞掉的异常，
Thread.getStackTrace()也拿不到线索 - APM 工具（如 SkyWalking、Pinpoint）无法上报这类“消失的异常”，监控断层
- 单元测试可能侥幸通过（因异常被吞），但集成环境必现失败
正确的异常处理方式
不是所有异常都要“捕获”，关键是判断：这个异常是否**当前层级有能力且应该处理**？否则应向上抛出或转为更明确的业务异常。
立即学习“Java免费学习笔记（深入）”；
-
记录日志 + 重新抛出：若需审计但无法修复，用
log.error("读取用户配置失败", e); throw e; -
转化为受检/业务异常：如
catch (IOException e) { throw new UserConfigLoadException("配置加载失败", e); } - 有明确兜底逻辑时才捕获：例如网络请求失败后自动重试、降级返回缓存值，并记录 warn 级日志
- 绝不忽略 RuntimeException：空指针、数组越界等通常反映代码缺陷，必须修复，而非捕获隐藏
团队协作与工程实践建议
单靠自觉难杜绝空 catch，需机制保障：
- 静态检查工具强制拦截：在 SonarQube 或 Checkstyle 中启用
IllegalCatchCheck或自定义规则，禁止空 catch 和裸catch (Exception) - 代码评审重点项：把 “是否有日志？是否真正处理了？能否向上抛？” 列为 PR 必查点
- 统一异常处理模板：在 Spring 中使用
@ControllerAdvice全局捕获，避免各处零散 try-catch
