为什么.NET（C#）转 Java 开发时常常在“吐槽”Java：checked exception

---

1. 定义与规范依据（基于 JLS）

根据《Java Language Specification》（JLS, Java SE 21 Edition）：

• Checked Exception ：指所有 Exception 的子类，但不包括 RuntimeException 及其子类，也不包括 Error（JLS §11.2）。

  // Checked: 必须处理
  IOException, SQLException, InterruptedException
  
  // Unchecked: 无需强制处理
  NullPointerException (extends RuntimeException)
  IllegalArgumentException (extends RuntimeException)
  OutOfMemoryError (extends Error)

• Catch or Specify Requirement（捕获或声明规则）（JLS §11.2）：

  "For each checked exception that a method can throw, the method must either:

  • catch it with a try-catch, or
  • declare it in its throws clause."

违反此规则 → 编译错误 。这是编译器强制执行的静态检查，而非运行时行为。

---

2. 设计初衷与历史背景

来源：James Gosling 等人在 1990 年代的设计思考

在《The Java Language Environment》（1995）白皮书中明确指出：

"One of the major design goals of Java was to help programmers write reliable programs...
We wanted to make sure that programmers think about exceptional conditions early in the design process."

核心动机：

• 防止开发者忽略可能发生的错误（如文件不存在、网络中断）；
• 将错误处理作为接口契约的一部分 （方法签名中的 throws 告知调用者"我可能失败"）；
• 提升大型系统中错误传播路径的可见性。

这与 C/C++ 中"错误码易被忽略"、C# 早期"全 unchecked"形成鲜明对比。

---

3. 工作机制：编译时强制，运行时无区别

特性	说明
编译时检查	编译器分析方法体中是否抛出 checked exception，若未捕获且未声明，则报错
运行时行为	一旦抛出，checked 与 unchecked exception 在 JVM 层完全相同：都沿调用栈 unwind，直到被捕获或导致线程终止
字节码层面	throws 声明仅存在于 .class 文件的 Exceptions 属性 中，供工具（如 javadoc、IDE）使用，JVM 执行时不验证

✅ 关键结论：checked exception 是纯编译期概念，不影响运行时性能或行为。

---

4. 实际使用中的问题与批评

(1) 破坏封装（Leaky Abstraction）

public void saveUser(User u) throws SQLException { // 暴露底层数据库细节
    db.insert(u);
}

→ 调用者被迫知道"保存用户可能涉及 SQL"，违反分层设计原则。

(2) 鼓励"空 catch"或"吞异常"

try {
    Files.readAllBytes(path);
} catch (IOException e) {
    // do nothing -- silent failure!
}

→ 开发者为"绕过编译错误"而写出危险代码，反而降低可靠性。

(3) 组合爆炸（Exception Proliferation）

当多个底层方法抛出不同 checked exception 时，上层方法需声明所有：

public void process() throws IOException, SQLException, ParseException { ... }

→ 接口变得臃肿，调用链污染严重。

(4) 函数式编程不友好

Java 8 引入 Lambda 后，函数式接口（如 Function<T,R>）不允许抛出 checked exception：

// 编译错误！Files.readAllBytes 抛出 IOException（checked）
List<byte[]> data = paths.stream()
    .map(Files::readAllBytes) // ❌ 不兼容
    .collect(toList());

→ 迫使开发者包装成 unchecked exception 或写冗长 try-catch。

---

5. 社区与官方的态度演变

社区主流观点（Stack Overflow、Reddit、InfoQ 调查）：

• 多数开发者认为 checked exception "理想很丰满，现实很骨感"；
• 许多现代 Java 框架（如 Spring）将 checked exception 包装为 unchecked （如 DataAccessException）。

官方立场（Oracle / OpenJDK）：

• 从未移除 checked exception（向后兼容性要求极高）；
• 未计划废除（JEP 讨论中多次出现，但均被否决）；
• 提供缓解方案 ：如 try-with-resources（简化资源管理）、更好的异常链（Throwable.getCause()）。

Java 之父 James Gosling 在 2018 年一次访谈中坦言：

"In retrospect, maybe we went a little too far with checked exceptions."

但这不代表官方承认设计错误 ，而是承认适用场景有限。

---

6. 与其他语言的对比

语言	异常模型	对比说明
C#	全 unchecked	微软认为"开发者应自行决定是否处理"，依赖文档和约定
Go	无异常，返回 (value, error)	显式错误检查，但无控制流中断
Rust	Result<T, E> + ? 操作符	编译时强制处理错误，但通过类型系统而非异常机制
Kotlin	全 unchecked（即使调用 Java checked 方法）	Kotlin 编译器忽略 checked 规则，视为 unchecked

→ Java 是主流语言中唯一坚持强制 checked exception 的。

---

7. 现代 Java 的应对策略

虽然无法改变语言规则，但社区发展出成熟模式：

(1) 将 checked exception 包装为 unchecked

try {
    return Files.readString(path);
} catch (IOException e) {
    throw new UncheckedIOException(e); // JDK 内置包装类
}

(2) 使用 Sneaky Throws

通过泛型擦除"欺骗"编译器（如 Lombok 的 @SneakyThrows），但不推荐生产使用。

(3) 设计时避免在 API 中暴露 checked exception

• 高层接口只抛出 unchecked exception；
• 底层实现内部处理或转换。

(4) 合理使用 try-with-resources

自动关闭资源，减少 finally 块中的异常处理复杂度。

---

总结：checked exception 的本质与定位

维度	结论
是否是"错误设计"？	❌ 不是。它是特定工程哲学下的合理选择，适用于高可靠、强契约场景（如金融交易）。
是否适合所有场景？	❌ 不是。在快速开发、函数式编程、微服务等场景中，其成本常大于收益。
Java 会移除它吗？	❌ 几乎不可能。破坏性太大，且仍有重要用户依赖它。
开发者该如何对待？	✅ 理解其意图，在底层 I/O/资源操作中保留，在业务 API 中尽量隐藏或转换。

checked exception 不是"bug"，而是一个"有代价的契约工具" 。

它的价值不在于"强制你处理错误"，而在于"强制你思考错误"。

正如 Effective Java（第3版，Item 71）所言：

"Use checked exceptions for recoverable conditions and unchecked exceptions for programming errors."

------可恢复的错误用 checked，程序逻辑错误用 unchecked。这才是其正确用法。

---