17370845950

受检异常是编译期契约而非强制加锁，用于显式建模外部依赖的不确定性；适用于可预见且可恢复的失败（如IO、SQL异常），需try-catch或throws处理，空catch、泛化捕获、盲目throws属典型误用。

受检异常不是“强制加锁”，而是编译期的契约提醒

Java 设计受检异常（Checked Exception）的根本目的，不是为了给开发者添麻烦，而是把

「外部依赖可能失败」这件事，从运行时黑箱提前拉到编译期白板上——它强制你在写代码时就回答一个问题：如果文件读不了、数据库连不上、网络超时了，你的程序打算怎么办？

这不是对“bug”的纠错，而是对“环境不确定性”的显式建模。比如调用 FileInputStream 构造函数会抛出 FileNotFoundException，编译器拦住你，不是说“你代码写错了”，而是说“这个文件是否存在，不归你代码控制，你得想好 fallback 路径”。

• 它只作用于继承自 Exception 但**不继承 RuntimeException** 的异常类型
• 典型代表：IOException、SQLException、ParseException、InterruptedException
• 如果你不 try-catch 或不 throws，编译直接报错：Unhandled exception type XXXException

什么时候该用受检异常？关键看“能否预见 + 是否可恢复”

受检异常适用于那些调用方大概率能预知、且有合理手段应对的失败场景。它的存在，本质是 API 设计者和调用者之间的一份轻量级协议。

• 适合场景：文件操作（readLine() 可能因磁盘满失败）、数据库查询（executeQuery() 可能因连接断开失败）、日期解析（SimpleDateFormat.parse() 可能因格式不对失败）
• 不适合场景：空指针（NullPointerException）、数组越界（ArrayIndexOutOfBoundsException）——这些是逻辑缺陷，该修复代码，不该靠 catch 来兜底
• 注意：InterruptedException 是个特例：它表示线程被中断，属于“协作式取消”信号，必须响应（通常要恢复中断状态或退出），不是随便吞掉的

为什么很多人反感受检异常？常见踩坑点

反感往往来自误用，而非设计本身。最典型的三个反模式：

• 空 catch 块：写个 catch (IOException e) { }，异常被静默吞掉，日志不打、提示没有、状态不重置——这比不加 try-catch 还危险
• 泛化捕获：用 catch (Exception e) 拦下所有异常，结果把本该崩溃的 NullPointerException 也一起掩盖了
• 盲目 throws 向上传递：在每一层都加 throws IOException，最后堆到 main 方法里再 throw，等于把责任踢给 JVM，没解决任何问题

更隐蔽的问题是：当业务逻辑嵌套多层（比如 Service → DAO → JDBC），一个底层的 SQLException 如果原样 throws 上来，上层根本不知道怎么处理——这时候应该封装成业务语义明确的自定义受检异常，如 OrderLockFailedException。

现代 Java 开发中，受检异常还值得坚持吗？

答案取决于上下文。Spring 等主流框架大量使用运行时异常（DataAccessException 继承 RuntimeException），是因为它把“数据访问失败”视为不可恢复的系统问题，而不是用户可预期的流程分支；而像 NIO 的 AsynchronousFileChannel 则完全回避受检异常，改用 CompletionHandler + 回调处理错误。

所以真正重要的不是“用不用”，而是是否让异常语义匹配真实控制力边界：

• 如果你能重试、降级、提示用户重填、切换备用源——那这个失败就值得用受检异常暴露出来
• 如果你什么都做不了，只能记录日志并告警——那它更适合作为运行时异常，由全局异常处理器统一拦截
• Java 8+ 的 Optional 和函数式接口（如 Supplier + 自定义包装）正在提供替代方案，但它们不改变核心原则：错误路径必须显式表达，不能靠运气躲过

最容易被忽略的一点是：throws 不是免责声明，而是调用契约的一部分；而 catch 之后不做任何事，等于签了字却没读条款。