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 是编译时契约，声明当前方法可能让谁来处理异常。
典型混淆点：
- 在
catch块里写throw e;（原样重抛） vsthrow new RuntimeException(e);（包装后转为 unchecked）——后者会丢失原始栈轨迹，应改用throw new RuntimeException(e);的构造函数支持 cause 传递 - 接口方法声明
throws IOException，但实现类却抛出SQLException—— 违反 Liskov 替换原则，调用方无法安全依赖接口契约 -
工具方法（如字符串转数字）抛出
IllegalArgumentException（unchecked），而非自定义 checked 异常——因为这是调用方传参错误，应提前校验，而不是靠异常流程兜底
异常链（cause）必须显式维护，否则调试信息断层
底层异常（如 NullPointerException）被包装成业务异常（如 PaymentFailedException）时，若未通过构造函数传入 cause，堆栈里就只剩最外层异常，原始根因丢失。
正确写法：
try {
processPayment();
} catch (RemoteException e) {
throw new PaymentFailedException("支付网关调用失败", e); // 传 e 作 cause
}
错误写法：
throw new PaymentFailedException("支付网关调用失败"); // cause 为 null
后续日志打印或监控系统依赖 getCause() 向下追溯，没有这层链路，排查线上问题时只能看到“支付失败”，看不到“是因为 Redis 连接超时”。
异常不是错误日志的替代品，它是可控的控制流分支；用错一次 throws，就可能让整条调用链失去错误感知能力。
