Java异常处理需厘清分类、传播与资源管理：checked异常强制处理，应转换为业务异常并保留cause；finally非绝对执行，推荐try-with-resources；throw抛实例，throws声明契约；异常链必须显式维护。
Java异常处理机制不是“加个 try-catch 就完事”，关键在于理解异常的分类边界、传播路径和资源管理责任——否则容易掩盖真实问题，或导致资源泄漏。
Checked 异常必须显式处理，否则编译失败
Java 把 Exception 及其子类（但不包括 RuntimeException）定义为 checked 异常。编译器强制你面对它：要么用 try-catch 捕获，要么在方法签名中用 throws 声明。
常见误操作：
- 用空
catch块吞掉IOException，结果文件没读到却无提示 - 在
main方法里盲目加throws Exception，把本该由业务层决策的问题甩给 JVM - 把
SQLException直接往上抛，却不考虑调用方是否能理解数据库语义
合理做法是：在 IO 或 DB 操作发生处捕获，转换为更上层可理解的业务异常（如 OrderNotFoundException），并保留原始异常作为 cause。
立即学习“Java免费学习笔记（深入）”；
finally 不等于“一定会执行”
finally 块在大多数情况下会执行，但有明确例外：
- JVM 退出（
System.exit(0)）时，finally被跳过 - 线程被强制中断（
Thread.stop()，已废弃但仍有遗留代码） -
finally前发生死循环或无限递归，导致控制流 never 到达
更可靠的做法是优先使用 try-with-resources（JDK 7+）自动关闭 AutoCloseable 资源，它本质是在编译期生成 finally 调用 close()，且对多个资源有确定关闭顺序。
try (FileInputStream fis = new FileInputStream("a.txt");
BufferedReader br = new BufferedReader(new InputStreamReader(fis))) {
return br.readLine();
} // fis 和 br 自动按声明逆序关闭
throw 和 throws 的职责完全不同
throw 是运行时动作，抛出一个异常对象；throws 是编译时契约，声明当前方法可能让谁来处理异常。
