受检异常必须处理但不必捕获，关键看当前层是否具备处理能力：能fallback、修复、清理或屏蔽细节时才捕获；仅记录再抛出、转为非受检异常或空catch均属错误；重抛需保留原始异常上下文。

受检异常必须处理，这是 Java 编译器的硬性要求——不 try-catch，就得在方法签名中 throws，否则编译直接失败。但“必须处理”不等于“一律捕获”，关键在于判断当前层是否具备处理能力与职责。

该捕获时：能做有意义的响应

只有当方法上下文可以执行具体恢复动作，捕获才有价值：

• 提供 fallback：如读配置失败时加载默认值，网络请求失败时返回缓存数据
• 局部修复：文件被占用时自动切换临时目录，连接超时后自动重试一次
• 资源清理：用 try-with-resources 确保流、连接等及时关闭，避免泄漏
• 屏蔽细节：UI 层统一转为用户友好的提示，不暴露底层 FileNotFoundException

不该捕获时：仅记录再抛出是典型误区

以下做法看似“处理了”，实则违背原则，削弱异常传播链：

• catch (IOException e) { logger.error("读文件出错", e); throw e; } —— 日志+原样 rethrow，没增加任何业务逻辑，不如直接 throws
• catch (SQLException e) { throw new RuntimeException(e); } —— 包装成非受检异常绕过编译检查，调用方失去处理机会
• 空 catch 块或只写 e.printStackTrace() —— 异常信号丢失，问题难以定位

重新抛出要讲方法

若需包装后向上抛，必须保留原始异常上下文：

• 用带 cause 构造器：例如 throw new ServiceException("数据库操作失败", originalException);
• 避免信息断层：堆栈跟踪应同时包含当前层和原始异常，方便逐层排查
• 不要混用记录与抛出：要么记日志后静默处理（已真正兜底），要么抛出交由上层决定，二者并行会导致重复日志干扰分析

记录本身不是目的，明确责任才是核心

受检异常的设计本意是让调用方意识到“这事可能出问题，你得想好怎么应对”。throws 不是甩锅，而是声明契约；try-catch 不是保险，而是承担恢复责任。方法签名里出现 throws IOException，就是在告诉调用者：“我干这件事依赖外部资源，出问题你要负责。”