Java异常沿调用栈向上冒泡，未捕获则JVM打印堆栈并终止线程；传播路径严格逆序回溯，无智能路由；受检异常须声明throws，运行时异常可省略；finally用于清理而非恢复，再抛异常会覆盖原始异常；包装异常必须保留cause链以保障调试信息。

异常不被捕获时，到底往哪跑？

Java 的异常默认会沿着方法调用栈向上“冒泡”，直到被 try-catch 捕获，或到达 main() 方法仍未处理——此时 JVM 打印堆栈并终止线程。

这不是“自动寻找 handler”，而是严格按调用链逆序查找：谁调了你，就传给谁；谁调了谁，就继续往上。没有“就近捕获”这种智能路由，只有机械回溯。

• 如果 methodC() 抛出 IOException，而 methodB() 只声明 throws SQLException 却没 catch，那异常直接穿透 methodB() 交给 methodA()
• RuntimeException 子类（如 NullPointerException）可以跳过 throws 声明，但传播路径完全一样——只是编译器不管它
• 一旦某个方法用 catch 吞掉异常又没重新抛出，传播就彻底中断；后续代码看不到这个异常，也收不到任何通知

为什么 throws 声明和实际抛出必须对得上？

这是编译期强制契约：throws 列出的，是该方法**可能向上抛出**的受检异常（Exception 及其子类，但排除 RuntimeException）。不对齐会导致编译失败，不是运行时问题。

• 写了 throws IOException，但方法体里只抛 IllegalArgumentException？编译通过——因为后者是运行时异常，不强制声明
• 写了 throws IOException，却在内部 throw new SQLException() 且没 catch？编译报错：“unreported exception SQLException”
• 子类重写父类方法时，throws 只能缩小范围（如父类声明 Exception，子类可改写为 IOException），不能扩大——否则破坏多态安全性

finally 一定会执行，但别指望它“兜底”异常

finally 块的核心价值是资源清理，不是错误恢复。它的执行优先级很高，但无法改变异常传播结果。

javascript-typescript-typescript-scaffold

你是 TypeScript 项目架构专家，专注于脚手架搭建生产就绪的 Node.js 和前端应用。生成包含现代工具链（pnpm、Vite、Next.js）、类型

下载

立即学习“Java免费学习笔记（深入）”；

• 如果 try 中抛出异常，catch 没处理而是直接 return，finally 仍会执行，但返回值已被锁定
• finally 里再抛新异常，会覆盖 try 中的原始异常——原始堆栈信息丢失，这是严重隐患
• 不要在 finally 里写业务逻辑判断，比如“如果异常是 X 就重试”——它本不该承担这个职责

异常链（cause）不是可选项，是调试刚需

当你要包装异常（比如把底层 SQLException 转成业务层 UserNotFoundException），必须用带 cause 的构造函数，否则原始错误上下文永久丢失。

throw new UserNotFoundException("User 123 not found", sqlEx); // ✅ 保留 cause

否则，日志里只剩顶层异常，排查时根本不知道数据库连接在哪断的。

• 用 e.getCause() 或 e.printStackTrace() 才能看到完整链路
• Lombok 的 @SneakyThrows 会绕过编译检查，但不会帮你维护异常链——手动包装时仍需显式传 cause
• Spring 等框架的全局异常处理器（@ControllerAdvice）依赖异常链还原原始错误，链断了就只能猜

异常传播看着是向上传递一个对象，实际传递的是整个调用现场的快照。栈帧、变量状态、甚至 JIT 编译痕迹都固化在 Throwable 里——所以别轻易 new Exception("xxx")，更别用字符串拼接掩盖真实原因。