当Java程序运行中出现错误，系统会创建一个异常对象并将其抛出。这个异常不会自动消失，而是沿着方法调用栈向上“传递”，直到被适当处理或导致程序终止——这就是异常传播机制的核心逻辑。
异常传播的基本路径
方法内部发生异常且未被捕获时，JVM会将该异常对象抛回给调用者方法。如果调用者也没有处理，异常继续向上传播，直到线程的顶层调用栈。若始终无人处理，线程将终止。
例如：方法A调用方法B，B调用方法C。若C抛出异常且B和C均未使用try-catch捕获，则异常会依次传回B、A，最后到JVM。
- 异常从发生点逐层回退，不跳过任何调用层级
- 检查型异常（checked exception）必须显式声明或捕获，否则编译失败
- 非检查型异常（如RuntimeException）虽可不声明，但传播行为一致
throws关键字的作用
通过在方法签名后添加throws声明，开发者明确告知调用者该方法可能抛出某些异常。这不仅是语法要求，更是接口契约的一部分。
立即学习“Java免费学习笔记（深入）”；
声明异常并不意味着一定会发生，而是提示调用方需准备应对可能性。
- 多个异常用逗号分隔
- 子类重写父类方法时，不能抛出更宽泛的异常类型
- 对于运行时异常，throws为可选；对于检查异常，为强制要求
try-catch如何中断传播链
一旦异常被catch块捕获并处理，传播过程立即终止。后续finally块通常用于资源清理，无论是否发生异常都会执行。
合理使用try-catch能有效控制异常影响范围，避免程序崩溃。
- catch块应按具体到通用的顺序排列，防止子类异常被父类捕获覆盖
- 可使用多重catch（|操作符）合并处理多种无关异常
- 重新抛出异常时建议保留原始异常信息（throw ex; 而非新建异常）
未捕获异常的最终归宿
每个线程都有一个未捕获异常处理器（UncaughtExceptionHandler）。当异常传播至栈顶仍未被捕获，线程将调用该处理器进行最后处理。
默认行为是打印堆栈跟踪并终止线程，但可通过Thread.setDefaultUncaughtExceptionHandler自定义全局策略。
- 可用于记录日志、发送告警或重启关键服务线程
- 主线程异常未处理会导致整个应用退出
- 多线程环境下尤其需要关注异常传播边界
基本上就这些。理解异常如何在调用栈中流动，有助于设计更健壮的错误处理逻辑。关键是明确谁负责处理、何时中断传播、以及如何安全地释放资源。不复杂但容易忽略细节。
