Java受检异常是1995年语言诞生时确立的独有机制，要求编译期必须显式处理继承自Exception（非RuntimeException）的异常，体现对外部可恢复风险的契约式建模。
Java的受检异常（Checked Exception）确实是主流编程语言中独一无二的设计，它不是语法糖，也不是临时补丁，而是1995年语言诞生时就写进规范的核心机制——至今仍是Java区别于C#、Go、Rust、Python等语言的标志性特征。
为什么说它是“独创”
其他语言基本都只保留非受检异常（即运行时异常）：
• C# 有 try-catch，但所有异常都是非受检的，编译器不强制处理；
• Go 用 error 返回值显式传递错误，彻底回避异常机制；
• Rust 用 Result
只有 Java 在编译期硬性规定：只要方法声明 throws 一个继承自 Exception（且非 RuntimeException）的类型，调用它就必须 try-catch 或继续 throws——否则编译直接失败。这个规则由 javac 强制执行，不依赖 IDE 或静态分析工具。
为什么从一开始就有争议
争议不是后来才出现的，而是伴随设计同步产生的： • 支持者认为：这是把“外部资源可能出问题”提前暴露在接口契约里，比如 FileInputStream 构造函数抛 FileNotFoundException，就是在告诉开发者：“文件是否存在不由你代码控制，请想好怎么应对”； • 反对者指出：现实业务中，很多底层异常（如 SQLException）层层透传到 Service 层，上层既无法恢复、也不该感知 JDBC 细节，结果只能写一堆无意义的 throws 或空 catch，反而掩盖真正问题； • 更关键的是：Java 是唯一把“是否必须处理”绑定到类继承关系（Exception vs RuntimeException）的语言，而这个分类本身依赖人工判断——比如 InterruptedException 既是受检的，又要求必须响应而非忽略，这种语义混杂加剧了理解成本。
新手容易误解的点
初学者常把“受检”等同于“严重”，其实完全不是： • IOException 很常见，但属于受检——因为磁盘、网络、权限等外部条件不可控，调用方理应准备 fallback； • NullPointerException 很危险，却是非受检——因为它暴露的是代码缺陷（没判空），应该修复逻辑，而不是靠 catch 补救； • 不是“Java 规定你必须处理”，而是“Java 要求你明确表达处理意图”：要么当场消化（try-catch），要么移交责任（throws），不允许沉默跳过。
它没被淘汰，但用法已进化
虽然 Spring、Hibernate 等主流框架普遍将原生受检异常包装为非受检的业务异常（如 DataAccessException），但 JDK 自身仍坚持使用： • Files.readString() 仍 throws IOException； • Class.forName() 仍 throws ClassNotFoundException； • Thread.sleep() 仍 throws InterruptedException。
这说明设计初衷没被否定，只是大家更清楚它的适用边界：它适合建模**可预见、外部导致、调用方有能力响应**的失败，而不适合封装逻辑错误或跨层透传的底层技术细节。
