Java异常处理的最佳实践：何时使用受检异常-Java面试题-PHP中文网

受检异常是强制调用方处理可预期、可恢复且需干预的外部失败的契约工具。适用场景有三：外部资源操作失败且有明确恢复路径、业务契约要求显式决策、启动阶段致命配置错误；其余如参数校验、编码缺陷、第三方异常包装等均不应使用。

java异常处理的最佳实践：何时使用受检异常

受检异常（Checked Exception）不是“该不该用”的问题，而是“该不该由你定义、该不该让调用方处理”的问题。它存在的意义，是把一种可预期、可恢复、且调用方有能力干预的外部失败，强制暴露在编译期——逼开发者面对它，而不是忽略它。

只有当同时满足“预期发生”“调用方能响应”“不处理就应编译失败”时，才考虑使用受检异常：

外部资源操作失败且有明确恢复路径：比如读取配置文件失败（IOException）、数据库查询超时（SQLException）。调用方可以重试、换备用源、降级返回默认值，或向用户提示具体原因。
业务契约要求显式决策：例如自定义支付接口抛出 InsufficientBalanceException extends Exception。这不是程序 bug，而是正常业务分支——调用方必须决定跳转充值页、冻结订单，或拒绝交易，不能静默吞掉。
启动或初始化阶段的致命配置错误：如解析 XML 配置时字段缺失或格式错误，抛出 InvalidConfigurationException extends Exception。这类错误应在系统启动时暴露，不允许带病运行。

强行套用只会增加调用方负担，却没带来实际收益：

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

参数校验失败：传入 null 或负数金额，应抛 IllegalArgumentException（RuntimeException 子类），这是逻辑错误，修复代码即可，无需调用方捕获。
空指针、数组越界等编码缺陷：属于 NullPointerException、IndexOutOfBoundsException，捕获它们掩盖了真正要修复的问题。
第三方 SDK 内部异常被层层包装成受检异常：比如把 HttpClient 的底层连接异常直接作为 public 方法的 throws 声明。调用方既无法理解含义，也无力干预，只能写一堆无意义的 try-catch。
所有 catch 块都只是打日志然后忽略：说明这个异常本质上不需要调用方做任何事，那它就不该是受检的。

微服务和 Web 场景下，统一异常处理器（如 Spring 的 @ControllerAdvice）已成标配。最终响应都是 HTTP 状态码 + 错误信息，受检与非受检在用户侧无差别。因此：

优先复用标准受检异常（如 IOException、SQLException），避免自定义——除非语义完全不可替代；
新设计的 API 接口，倾向用非受检异常封装业务错误（如 BusinessException extends RuntimeException），配合全局兜底；
若仍需受检异常，确保每个 throws 都对应一个真实、可执行的恢复动作，而不是形式主义。

本质上，受检异常不是语法糖，而是一种契约设计工具。用得好，它让接口意图清晰、错误路径可控；用得滥，它就成了代码里的噪音。