java异常传播是异常对象沿调用栈向上传递的过程，jvm自动将未捕获异常逐层抛给调用者，直至被捕获或由默认处理器终止线程；通过throws声明上抛、throw重抛或包装异常可控制传播，分层架构中dao层抛出、service层转换、controller层交由全局处理器统一响应。
Java 中异常的传播机制，本质是异常对象沿着方法调用栈向上传递的过程。它不是错误本身在“移动”，而是 JVM 自动将未捕获的异常实例逐层抛给上一个调用者，直到被 try-catch 捕获，或最终交由 JVM 默认处理器终止线程。
异常传播的基本路径
当某个方法中发生异常且未被本地 try-catch 处理时，该异常会立即中断当前方法执行，并向上抛给它的直接调用方。这个过程持续进行，形成清晰的调用链：
- DAO 层抛出
SQLException→ Service 层未捕获 → 异常传至 Controller 层 - Controller 层也未捕获 → 异常到达 Spring MVC 的 DispatcherServlet → 最终由全局异常处理器或容器默认机制响应（如返回 500 错误页）
- 若全程无任何捕获，JVM 打印完整堆栈跟踪并终止当前线程
控制传播方向的两种核心手段
开发者可通过语法明确干预传播行为，决定异常“停在哪里”或“变成什么”：
-
使用
throws声明继续上抛：在方法签名后添加throws IOException等，表示“我不处理，但调用我的人必须面对”。这仅对检查型异常（checked exception）强制生效 -
使用
throw主动重抛或转换：在catch块中，可直接throw e;原样上抛；更常见的是throw new BusinessException("操作失败", e);——包装原始异常，保留根因（cause），同时升级为业务语义更清晰的新异常
分层架构中的典型传播策略
在 Web 应用三层结构中，传播不是放任不管，而是按职责分级响应：
-
DAO 层：通常不捕获数据库异常，而是声明
throws SQLException，让问题暴露到上层 -
Service 层：聚焦业务逻辑，捕获底层异常后转换为统一的
BusinessException，屏蔽技术细节，避免把SQLTimeoutException直接透传给前端 -
Controller 层：一般不写具体
catch，而是依赖全局异常处理器（@ControllerAdvice）统一拦截、记录日志、返回标准化 JSON 错误响应
避免传播失控的实用提醒
传播机制虽自动，但滥用会导致问题难以定位或掩盖真实原因：
- 不要在
finally或catch末尾写return，它会吞掉原异常，使堆栈信息丢失 - 捕获异常后若选择忽略（空
catch）或仅打印e.printStackTrace()而不记录日志，等于切断传播线索 - 自定义异常务必通过构造函数传入原始异常（
super(message, cause)），确保getCause()和日志中的嵌套堆栈可用
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
