Java中异常是否中断程序取决于类型和处理方式：未捕获的运行时异常（如NullPointerException）立即终止当前线程执行；检查型异常（如IOException）必须显式处理，否则编译失败，若最终未捕获也会中断执行；finally块几乎总执行但不能阻止异常传播。
Java中异常是否中断程序，取决于异常类型和是否被处理：未捕获的 RuntimeException 及其子类（如 NullPointerException、ArrayIndexOutOfBoundsException）会中断当前线程的执行流程；而 Exception 的检查型子类（如 IOException）必须显式处理（try-catch 或 throws），否则编译不通过——但一旦抛出且未被捕获，同样中断执行。
运行时异常（unchecked）直接终止当前方法调用栈
这类异常继承自 RuntimeException，JVM 不强制要求处理。一旦抛出，会立即停止当前方法剩余语句的执行，并向上层调用栈回溯，直到遇到匹配的 catch 块或线程终止。
- 常见表现：控制台打印堆栈，程序输出戛然而止（除非在
main外有全局异常处理器） -
System.out.println("A"); throw new NullPointerException(); System.out.println("B");——"B"永远不会输出 - 即使在
循环中，单次迭代抛出未捕获的
RuntimeException，也会跳出该次迭代并终止整个循环后续执行（除非try-catch包裹在循环体内）
检查型异常（checked）必须显式声明或捕获，否则编译失败
像 IOException、SQLException 这类异常，编译器会强制你面对它们。它们本身不“自动中断”程序，但如果你选择 throws 而不处理，最终仍可能在调用链顶端因未捕获而中断；若用 try-catch 捕获，则程序可继续执行。
- 没写
try-catch也没加throws→ 编译报错：Unhandled exception type XXXException - 写了
throws IOException但调用方也不处理 → 异常最终传播到main，导致线程终止 - 在
catch块里只打印日志、不重新抛出 → 当前方法可正常返回，后续逻辑继续
finally 块几乎总能执行，但不是“万能兜底”
finally 块的设计目标是确保清理逻辑（如关闭文件、释放锁）被执行，但它不能阻止异常传播，也不能在所有情况下运行。
- 正常情况：无论
try中是否抛异常、是否被catch，finally都会执行（在catch后、方法返回前） - 例外情况：
System.exit()直接终止 JVM；try或catch中发生ThreadDeath（已废弃）；JVM 崩溃或断电 - 注意：
finally中如果也抛异常，会覆盖try中的异常（除非使用 try-with-resources 或显式抑制）
public static void example() {
try {
throw new RuntimeException("from try");
} catch (RuntimeException e) {
System.out.println("caught: " + e.getMessage());
throw new RuntimeException("from catch"); // 新异常将传播出去
} finally {
System.out.println("finally runs"); // 这行会输出
// 如果这里 throw 新异常，它会成为最终抛出的异常
}
}
真正容易被忽略的是：异常中断的是「当前线程」的执行流，不是整个 JVM。多线程环境下，一个线程崩溃默认不会杀死其他线程（除非共享状态被破坏或使用了 UncaughtExceptionHandler 主动干预）。另外，return 和异常同时存在时的执行顺序（比如 try 里有 return，finally 里也有 return）会导致实际返回值被覆盖——这种细节在真实业务逻辑中极易引发隐蔽 bug。
