空 catch 块会静默吞掉异常，掩盖问题根源，导致调试困难、监控失真、排障失效，违反防御性编程原则；正确做法是至少记录异常并保留堆栈，分类处理或明确注释极少数允许场景。
在 catch 块中留空（即只写 catch { } 或 catch (Exception e) { } 而不处理或记录异常），本质上是主动屏蔽错误信号，会让程序在出错时“假装无事发生”，从而掩盖问题根源，增加调试难度和线上风险。
异常被静默吞掉，问题无法暴露
留空的 catch 会终止异常传播链，本该中断执行或触发告警的地方变得悄无声息。比如网络请求失败、文件读取权限不足、JSON 解析异常——这些本应被发现的故障，可能变成用户看到“页面空白”“按钮无响应”等模糊现象。
- 开发阶段难以定位：IDE 不报错，日志里没有痕迹，断点也跳过了关键路径
- 测试阶段容易漏检：自动化用例可能因“没抛异常”而误判为成功
- 上线后雪球效应：小错误积累成数据不一致、状态错乱甚至服务雪崩
掩盖真正的失败原因，干扰排障逻辑
很多异常是链式发生的。例如数据库连接失败 → 导致事务回滚异常 → 进而引发空指针。如果中间某层把第一个异常吃掉了，后续堆栈就丢失上下文，运维或开发看到的只是最后一环的“NullPointerException”，却找不到源头。
- 日志缺失关键信息：没有异常类型、消息、堆栈，无法区分是偶发超时还是配置错误
- 监控指标失真：错误率归零，但业务成功率实际下降，告警阈值失效
- 重试/降级策略失效：系统不知道该不该重试，因为连“失败了”都不知道
违反防御性编程原则，降低代码可维护性
空 catch 让调用方失去对异常流的控制权，也向其他开发者传递错误信号：“这里不会出问题”或“出问题也不重要”——而这往往与事实相反。
- 后续修改者可能误以为该处逻辑已完备，不敢加校验或补偿逻辑
- 静态扫描工具（如 SonarQube、Checkstyle）通常会将空 catch 标为严重缺陷
- 不符合主流规范：Java 的 Effective Java、.NET 的 Microsoft Docs、Python 的 PEP 8 都明确反对忽略异常
正确做法：至少记录，按需处理
不是所有异常都要“修复”，但必须让它们可见、可追溯、可决策。
-
最低要求：记录异常（
logger.error("描述性消息", e)），包含上下文（如用户ID、订单号、操作步骤） - 推荐做法：分类处理——可恢复的（如网络抖动）加重试；需人工介入的（如配置错误）打告警；业务规则类的（如余额不足）转为用户友好的提示
- 特殊允许空 catch 的极少场景：仅限明确知道异常必然发生且完全无害，且有充分注释说明原因（例如某些平台 API 在资源不存在时抛出异常，而“不存在”正是预期状态）
