空catch块不可接受，因它丢失异常堆栈、导致调用方误判失败、破坏可观测性；最低要求是记录error日志并包含完整堆栈和上下文；应按异常性质分类处理，优先预防或使用try-with-resources。
受检异常（Checked Exception）必须显式处理，但“处理”不等于简单地用空的 catch 块包裹。空 catch 是严重的设计缺陷，它让异常无声消失，掩盖真实问题，破坏可维护性与可观测性。
为什么空 catch 块不可接受
受检异常本身已由编译器强制要求捕获或声明，说明 JVM 认为该异常是业务中可能合理发生的、应被关注的错误场景（如文件不存在、网络超时、SQL 语法错误）。若在 catch 中不做任何事：
- 异常堆栈和上下文信息彻底丢失，日志里查不到线索
- 调用方无法感知操作失败，可能继续执行后续逻辑，导致数据不一致或状态错乱
- 测试难以覆盖，问题常在生产环境突然暴露
- 违反“异常即信号”的设计本意——它不是噪音，而是需要响应的事件
必须做的最低动作：至少记录日志
哪怕当前阶段不打算恢复或重试，也必须保留可追溯性：
- 使用日志框架（如 SLF4J）记录 ERROR 级别日志，包含异常消息和完整堆栈：
logger.error("读取配置文件失败", e); - 避免仅打印
e.getMessage()—— 它常为空或无意义；printStackTrace()不适合生产环境，应交由日志系统统一管理 - 如有关键上下文（如文件路径、用户ID、请求ID），一并写入日志字段，便于链路追踪
更合理的处理方式：按异常性质分类应对
不是所有受检异常都该被“吞掉”。应结合业务语义决定下一步动作：
-
可恢复异常（如临时网络抖动导致的
IOException）：加入有限重试 + 指数退避，并在最终失败时记录完整错误 -
需用户反馈的异常（如
SQLException因参数非法触发唯一约束）：转换为带明确提示的业务异常，抛给上层返回友好提示 -
应提前规避的异常（如
FileNotFoundException）：优先在 try 前做存在性检查（Files.exists()），把部分受检异常转为预防性逻辑，减少异常流路径
用 try-with-resources 替代手动 close + 空 catch
很多受检异常（如 IOException）源于资源未正确关闭。与其在 finally 里手动 close() 并用空 catch 吞掉关闭异常，不如直接用 try-with-resources：
- 自动调用
close()，且会抑制（suppress）关闭阶段抛出的次要异常 - 主异常（如读取时的
IOException）仍会被抛出，保证核心错误不丢失 - 代码更简洁，无需写额外的
finally或空catch
