try-catch-finally执行顺序固定：无论try是否抛异常、是否return，finally几乎总在退出前执行；若finally含return，则覆盖try/catch的返回值或异常。
try-catch-finally 的执行顺序是固定的，但 return 和异常会改变控制流
Java 异常处理的执行顺序不是“先 catch 再 finally”这么简单——finally 块几乎总会在 try 或 catch 退出前执行，哪怕里面写了 return。关键在于：JVM 会把 finally 插入到每个可能的出口路径上，包括隐式抛出异常、显式 return、break、continue。
常见误解是“catch 执行完就结束”，其实只要 finally 存在，它就会介入：
- 如果
try中抛异常 → 跳转到匹配的catch→ 执行catch→ 执行finally→ 离开方法 - 如果
try中无异常 → 直接跳过catch→ 执行finally→ 离开方法 - 如果
try或catch中有return→ JVM 记下返回值 → 强制执行finally→ 再返回（除非finally自己也return）
finally 里的 return 会覆盖 try/catch 中的 return
这是最易踩坑的一点：finally 块里写 return，会直接终结方法，丢弃 try 或 catch 中已计算好的返回值。编译器不会报错，但逻辑会被静默覆盖。
public static String test() {
try {
return "from try";
} finally {
return "from finally"; // ✅ 实际返回这个，"from try" 被丢弃
}
}
同理，如果 catch 抛出新异常，而 finally 也抛异常，后者会完全压制前者（try 原始异常丢失）：
立即学习“Java免费学习笔记（深入）”；
public static void badExample() {
try {
throw new RuntimeException("original");
} catch (RuntimeException e) {
throw new RuntimeException("in catch");
} finally {
throw new RuntimeException("in finally"); // ✅ 这个异常被抛出，前两个都丢了
}
}
try-with-resources 的 close() 调用时机和异常压制
try-with-resources 本质是语法糖，编译后自动展开为 try-finally，并在 finally 中调用 close()。它的执行顺序是：
- 正常执行完
try块 → 进入隐式finally→ 按声明逆序调用各资源的close() - 如果
try块抛异常 A，且某个close()也抛异常 B → A 是主异常，B 被添加为suppressed异常（可通过getSuppressed()获取） - 如果
try块没异常，但close()抛异常 → 该异常就是方法抛出的唯一异常
注意：资源必须实现 AutoCloseable；多个资源用分号隔开，关闭顺序与声明顺序相反。
throw 和 throws 对执行流的影响差异
throw 是运行时动作，立即中断当前执行路径，向上抛出异常对象；throws 只是方法签名声明，不改变流程，只告诉调用者“我可能抛这个异常”。两者常被混淆：
-
throw new IOException()→ 当前方法立刻退出，控制权交还给调用栈上层 -
public void read() throws IOException→ 编译器强制调用方处理或再声明，但方法体内部仍按顺序执行 - 若方法既声明了
throws，又在内部throw，但没try住 → 编译失败（对受检异常） - 运行时异常（如
NullPointerException）可throw而不声明throws
真正影响执行顺序的是 throw 动作本身，不是 throws 声明。很多人调试时卡在“明明写了 throws 却没进 catch”，其实是没在调用链上真正 throw 出来，或者被中间某层吞掉了。
