开篇：你写的 try-catch，正在「吞掉」线上故障信号
先来看一段你肯定写过的「典型错误代码」，在 DAO 层读取业务数据时，捕获了SQLException但只打印了一行日志，没有继续向上抛出异常：
public class UserDao {
  // 错误实现：吃掉了SQLException，上层业务感知不到数据库操作失败
  public User queryUserById(Long id) {
  String sql = "SELECT \* FROM user WHERE id = ?";
  try (Connection conn = DriverManager.getConnection(DB\_URL);
  PreparedStatement pstmt = conn.prepareStatement(sql)) {
  pstmt.setLong(1, id);
  ResultSet rs = pstmt.executeQuery();
  if (rs.next()) {
  return new User(rs.getLong("id"), rs.getString("name"));
  }
  } catch (SQLException e) {
  // 仅打印日志，没有向上抛出异常！上层方法感知不到数据库操作异常
  e.printStackTrace();
  }
  return null;
  }
}然后在 Service 层调用这个 DAO 方法时，直接判断结果为null就返回了「用户不存在」的业务提示，完全没有感知到数据库操作的异常：
public class UserService {
  private UserDao userDao = new UserDao();
  public User getUserById(Long id) {
  User user = userDao.queryUserById(id);
  if (user == null) {
  // 问题根源：无法区分是「用户数据不存在」还是「数据库查询操作失败」
  throw new BusinessException("用户不存在");
  }
  return user;
  }
}这段代码在正常情况下可以运行，但在生产环境中，如果数据库连接超时、SQL 语法错误或表结构被修改，DAO 层的SQLException会被完全吃掉 ------Service 层拿到null结果，会默认返回「用户不存在」的提示，相当于把「数据库异常」悄悄伪装成了「业务正常提示」。最终的结果是：前端用户看到错误的业务提示，后端服务的业务逻辑执行失败，运维和开发人员却无法在日志中定位故障根源。
这就是典型的异常传播失败：方法在捕获异常后，没有正确将异常向上传递，导致调用链上层无法感知到异常的发生，将技术异常掩盖为了正常业务场景。
Java 的异常处理机制，本质是一套故障分层通知体系 。而「异常传播」是这套机制的核心 ------ 如果搞不懂异常传播的逻辑，写再多的try-catch也只是在「掩盖故障」，而不是在「处理故障」。
第一部分：前置基础复盘 ------ 异常的本质与分类逻辑
在讲解异常传播机制前，我们需要先快速复盘 Java 异常体系的核心基础，这是理解传播机制的前提。很多开发者会混用异常类型，本质是没有理解不同类型异常的适配场景。
1.1 异常的本质：程序的故障通知信号
异常是 Java 对程序运行中出现的非正常情况 的封装 ------ 比如数据库连接失败、文件找不到、参数校验不通过、空指针访问。它的本质是一套故障通知信号体系，将底层的故障信息，从发生地逐层传递到能够处理它的上层业务逻辑中，实现故障的集中处理或容错。
这就好比你在酒店点餐，厨房发生了设备故障，服务员不会直接把故障细节告诉你，而是将故障信息转述给前台客服，再由前台统一协调处理或告知你情况 ------ 异常传播的逻辑，和这个过程完全一致。
1.2 异常的分类：检查型异常 vs 非检查型异常
Java 的所有异常，都继承自java.lang.Throwable类，核心分为三大类：Error、Exception、RuntimeException，其中Exception又分为检查型异常 （Checked Exception）和非检查型异常（Unchecked Exception）。
不同类型的异常，在传播规则和使用场景上存在差异，这是后续传播机制的基础前提。
1.2.1 核心分类对比
| 分类 | 触发时机 | 处理要求 | 核心适配场景 | 典型代表 |
|---|---|---|---|---|
| 检查型异常（Checked Exception） | 编译期 | 必须在代码中显式捕获（try-catch）或继续向上抛出（throws），否则代码无法通过编译 |
外界环境相关的可恢复故障：数据库连接失败、文件不存在、网络请求超时 | SQLException、IOException、ClassNotFoundException |
| 非检查型异常（Unchecked Exception） | 运行期 | 不强制要求捕获或抛出，编译期无强制约束 | 程序逻辑错误、传参错误：空指针、数组越界、参数校验失败、非法方法调用 | NullPointerException、IllegalArgumentException、BusinessException |
| 错误（Error） | 运行期 | 不建议捕获，一般由 JVM 处理 | 系统级 fatal 故障：内存溢出、栈溢出、类文件加载失败 | OutOfMemoryError、StackOverflowError |
关键设计结论：检查型异常强制开发者必须处理故障风险，保障程序的健壮性；非检查型异常用于标记程序本身的逻辑错误，或者需要上层业务统一感知处理的故障场景；而
Error是系统级的严重故障，应用程序一般无法处理，不需要在代码中捕获。
1.2.2 异常的核心语法关键字
异常处理的核心语法有 5 个，是实现异常传播的基础工具，你需要精准理解每个关键字的作用，避免在传播逻辑中使用错误：
| 关键字 | 作用描述 |
|---|---|
try |
包裹可能抛出异常的代码块，定义异常的捕获范围 |
catch |
捕获try代码块中抛出的指定类型异常，定义异常处理逻辑 |
finally |
无论是否捕获到异常，都会执行的代码块，一般用于释放资源 |
throw |
手动抛出一个异常对象，用于主动终止业务逻辑，向上传递故障信号 |
throws |
用在方法签名上，声明该方法可能抛出的指定类型异常，告知调用方必须处理或继续传递该异常 |
第二部分：核心原理深入拆解 ------ 异常传播的底层机制
「异常传播」是指异常从发生位置开始，沿着方法调用链，逐层向上传递的过程------ 这是异常处理机制的核心底层逻辑，也是绝大多数开发者最容易理解偏差的环节。
2.1 异常传播的核心规则
当一个方法抛出异常后，Java 虚拟机会按照以下顺序，来处理这个异常，决定异常的最终传播路径：
- 优先查找当前方法的 catch 块 ：如果当前方法的
try-catch块，可以捕获该类型的异常，就会执行对应catch块中的处理逻辑； - 未捕获则向上传递给调用方 ：如果当前方法没有捕获该异常，或者捕获后没有对其进行处理，异常会被自动传递给当前方法的调用方，即方法调用链的上一层；
- 逐层重复上述逻辑：这个传递过程会一直重复，直到异常被某一层调用方捕获处理，或者传递到方法调用链的最顶层；
- 顶层未捕获则由 JVM 终止线程 ：如果异常传递到线程的最顶层（比如
main方法或线程的run方法），仍然没有被捕获，JVM 会打印异常的栈追踪信息，然后终止当前线程的执行 ------ 如果是主线程，整个应用程序会直接停止运行。
2.2 异常传播的流程示意图
下面的示意图展示了异常传播的完整路径，对应后续的分层架构实战场景：
graph TD
A[顶层：Controller层] --> B[Service层]
B --> C[DAO层]
C --> D[数据库操作：抛出SQLException]
D --> C{DAO层是否捕获？}
C -->|No| B{Service层是否捕获？}
B -->|No| A{Controller层是否捕获？}
A -->|No| E[JVM终止线程，打印栈日志]
C -->|Yes| F{DAO层是否重新抛出？}
F -->|No| G[异常被吃掉，传播终止]
F -->|Yes| B
B -->|Yes| H{Service层是否重新抛出？}
H -->|No| G
H -->|Yes| A
A -->|Yes| I[Controller层统一处理异常]从图中可以清晰看到：只要在传播链上的任意一层，捕获异常后不重新抛出，异常传播就会被截断，导致上层调用方无法感知到异常，这也是最容易导致线上故障的场景。
2.3 传播的核心语法支撑：throws 与 throw
要实现异常的传播，必须精准使用throws和throw这两个关键字，二者的搭配使用，是构建正确传播链路的核心前提。
2.3.1 throws：声明方法的异常传播能力
throws关键字用在方法签名的尾部，用来声明该方法可能抛出的异常类型，它的核心作用是：
- 告知该方法的调用方："我这个方法内部可能抛出声明中的异常，你在调用我的时候，必须捕获处理这个异常，或者继续向上抛出"；
- 配合方法调用链，将异常的处理责任，从底层方法，转移到上层调用方，实现异常的逐层传播。
重要设计原则：一个方法如果无法处理某种异常，就必须在方法签名上使用
throws声明该异常，不要在当前方法中用空的
catch块吃掉异常，或者只打印日志不重新抛出，截断异常传播链路。
2.3.2 throw：主动抛出异常，触发传播
throw关键字用在方法内部，用来手动抛出一个异常对象，它的核心作用是：
- 当程序出现非正常情况时，主动终止当前的业务逻辑执行；
- 将创建好的异常对象，按照调用链，向上传递给上层调用方，触发异常传播机制。
重要设计原则：
throw抛出的必须是一个
Throwable类的实例对象，或者它的子类实例，不能直接抛出一个字符串、数字或其他非
Throwable类型的对象；同时，不要在业务代码中随意抛出
Exception这类泛化的异常类型，要使用精准的异常类型，或自定义业务异常类。
2.3.3 二者的组合使用示例
下面的代码演示了throws和throw的正确组合使用方式，实现异常的向上传播：
public class ThrowThrowsDemo {
  // 方法签名声明：该方法可能抛出SQLException，调用方必须处理或继续向上抛出
  public void daoOperate() throws SQLException {
  // 模拟业务逻辑校验：检测到数据库连接异常
  boolean dbConnError = true;
  if (dbConnError) {
  // 主动抛出SQLException异常，触发异常传播机制
  throw new SQLException("数据库连接失败：连接超时");
  }
  }
  public void serviceOperate() throws SQLException {
  // 调用daoOperate方法，由于该方法声明了throws，这里必须捕获或继续抛出
  daoOperate();
  }
  public static void main(String\[] args) {
  ThrowThrowsDemo demo = new ThrowThrowsDemo();
  try {
  // 调用serviceOperate方法，继续向上捕获异常
  demo.serviceOperate();
  } catch (SQLException e) {
  // 顶层方法捕获异常，统一处理故障：打印日志、返回错误提示
  System.out.println("捕获到异常：" + e.getMessage());
  }
  }
}在这个示例中，daoOperate()方法抛出的SQLException，会沿着daoOperate() → serviceOperate() → main()的调用链逐层向上传播，最终在main()方法中被捕获，完成了完整的异常传递链路。