为什么在 catch 块中留空是危险的

空 catch 块会静默吞掉异常，掩盖问题根源，导致调试困难、监控失真、排障失效，违反防御性编程原则；正确做法是至少记录异常并保留堆栈，分类处理或明确注释极少数允许场景。

在 catch 块中留空，也就是只写个 catch { } 或者 catch (Exception e) { } 却不做任何处理——这本质上是在主动屏蔽错误信号。程序出错了，但看起来“一切正常”，于是问题被悄悄藏起来，调试变得困难，线上风险也随之堆积。

异常被静默吞掉，问题无法暴露

空 catch 会直接切断异常传播链。本该中断执行、触发告警的地方，现在变得悄无声息。想象这样的场景：网络请求失败、文件读取权限不足、JSON 解析异常——这些本应被发现的故障，最终可能只表现为用户看到的“页面空白”或“按钮无响应”。模糊的体验背后，是开发、测试、运维三个环节的集体失明。

• 开发阶段难以定位：IDE 不报错，日志里没有痕迹，断点也跳过了关键路径
• 测试阶段容易漏检：自动化用例可能因为“没抛异常”而误判为通过
• 上线后雪球效应：小错误积累成数据不一致、状态错乱，甚至引发服务雪崩

掩盖真正的失败原因，干扰排障逻辑

错误往往是链式发生的。举个例子：数据库连接失败 → 导致事务回滚异常 → 进而触发空指针。如果中间某层把第一个异常吃掉了，后续的堆栈就丢失了关键上下文。运维或开发看到的只是最后一环的 NullPointerException，却怎么也找不到源头。

• 日志缺失关键信息：没有异常类型、消息、堆栈，也就无法区分是偶发超时还是配置错误
• 监控指标失真：错误率归零，但业务成功率实际在下降，告警阈值形同虚设
• 重试/降级策略失效：系统连“失败了”都不知道，更谈不上该不该重试

违反防御性编程原则，降低代码可维护性

空 catch 让调用方失去了对异常流的控制权，同时也向其他开发者传递了错误信号：“这里不会出问题”或“出问题也不重要”。但现实往往恰恰相反。

• 后续修改者可能误以为该处逻辑已完备，不敢再加校验或补偿逻辑
• 静态扫描工具（如 SonarQube、Checkstyle）通常会将空 catch 标记为严重缺陷
• 不符合主流规范：无论是 Ja va 的《Effective Ja va》、.NET 的官方文档，还是 Python 的 PEP 8，都明确反对忽略异常

正确做法：至少记录，按需处理

并不是所有异常都需要“修复”，但必须让它们可见、可追溯、可决策。这才是负责任的做法。

• 最低要求：记录异常（logger.error("描述性消息", e)），并且带上上下文信息，比如用户ID、订单号、操作步骤
• 推荐做法：分类处理——可恢复的（如网络抖动）加重试；需要人工介入的（如配置错误）打告警；业务规则类的（如余额不足）转为用户友好的提示
• 特殊允许空 catch 的极少场景：只有明确知道异常必然发生且完全无害的情况，并且必须有充分注释说明原因。例如某些平台 API 在资源不存在时会抛出异常，而“不存在”本身就是预期状态