Java受检异常使用场景详解

Java中checked异常适用于调用方能且应主动处理的预期外部故障，如IOException、SQLException；不适用于逻辑错误、系统错误或无法干预的第三方异常，现代实践倾向减少使用。

Java中使用checked异常（受检异常）的核心原则是：当某个异常情况预期可能发生、调用方有能力且应当主动处理，并且不处理就编译不通过时，才定义为checked异常。

需要调用方显式决策恢复策略的场景

这类异常代表外部环境导致的、程序逻辑无法完全规避的问题，调用者必须考虑“怎么应对”，而不是忽略。

• 文件读写失败（IOException）：磁盘满、权限不足、路径不存在——调用方可能重试、换路径、提示用户或记录日志
• 网络连接异常（SQLException、MalformedURLException）：数据库宕机、URL格式错误——调用方可能降级、返回默认值或抛出业务异常封装
• 类加载失败（ClassNotFoundException）：动态加载类时类名拼错或jar未引入——调用方需明确是否允许失败、是否有备用类

业务契约要求强制处理的流程性异常

在框架或API设计中，用checked异常表达“这一步失败了，你必须明确响应”，形成清晰的调用契约。

• Spring事务中声明TransactionRequiredException（虽然它实际是unchecked，但对比说明：若设计为checked，则调用方必须catch或throws，避免无事务执行关键操作）
• 自定义支付接口抛出InsufficientBalanceException extends Exception：余额不足不是bug，是常见业务状态，调用方应跳转充值页而非崩溃
• 解析配置文件时抛出InvalidConfigurationException：配置错误应在启动时暴露，不允许静默忽略

不适用checked异常的典型情况

这些情况即使编译器允许，也不应强行用checked异常：

• 程序逻辑错误（空指针、数组越界、类型转换失败）——属于RuntimeException，应修复代码，而非让调用方处理
• 系统级不可恢复错误（内存溢出、栈溢出）——JVM层面问题，捕获无意义
• 第三方SDK内部异常被过度包装成checked——增加调用负担，且调用方通常无力干预（如把HttpClient底层IO异常直接暴露给业务层）
• 所有分支都只是打印日志+忽略——说明本就不该是checked，而是用unchecked或直接返回错误码

现代实践中的谨慎倾向

从Java 7起，try-with-resources和多异常捕获简化了checked异常处理，但业界更倾向减少其使用：

• 多数Web/微服务场景中，统一异常处理器（@ControllerAdvice）捕获所有异常并转为HTTP状态码，checked与unchecked在最终响应上无差别
• Lombok的@SneakyThrows常用于绕过checked异常强制声明，侧面反映其使用成本偏高
• 函数式接口（如Function）不支持throws checked异常，迫使封装或转为unchecked