多层调用中异常传递的核心是明确处理责任：检查型异常须显式处理或向上声明，运行时异常应自然抛出由全局处理器拦截；禁用空throw，须用带cause的包装异常保留上下文；跨层统一用语义化业务异常替代技术异常；资源清理（如try-with-resources）不干扰异常传播。
多层调用中正确传递异常，核心是明确“谁该处理、谁该声明、谁该包装”，避免吞掉异常、掩盖根源或破坏上下文。关键不在层层 catch，而在有意识地控制传播路径。
明确异常类型决定传递策略
检查型异常（如 IOException、SQLException）必须显式处理：要么在当前层 try-catch 并转化为业务可理解的动作（如重试、降级），要么用 throws 向上声明，把责任交给更上层——通常是能决定业务走向的 Service 或 Controller 层。
运行时异常（如 NullPointerException、IllegalArgumentException）原则上不应被中间层静默捕获。它们代表代码缺陷或非法输入，应让其自然向上抛出，直至被全局异常处理器（如 Spring 的 @ControllerAdvice）统一拦截并记录，便于定位和修复。
避免“空 throw”和裸 re-throw
不要写这样的代码：
catch (IOException e) { throw e; } —— 丢失了原始堆栈起点，也未补充上下文。
推荐做法是保留异常链：
- 用 throw new BusinessException("文件读取失败", e) 包装后抛出，既保留原始异常（
e作为 cause），又赋予业务语义 - 若需修改异常类型但不想丢上下文，用 throw new CustomException(e.getMessage(), e)，确保构造函数调用
super(message, cause)
跨层时统一用自定义业务异常包装
DAO 层抛出 SQLException，Service 层不直接暴露给 Controller。而是转换为语义清晰的业务异常：
-
UserNotFoundException 替代
EmptyResultDataAccessException -
OrderLockedException 替代底层乐观锁失败抛出的
OptimisticLockException
这样上层只关注“用户找不到”或“订单已被锁定”，无需了解数据访问细节，也便于前端做精准错误提示。
资源清理与异常传递不冲突
使用 try-with-resources 自动关闭资源，它不会干扰异常传播逻辑：
try (FileInputStream fis = new FileInputStream("a.txt")) { ... } —— 即使 fis.read() 抛异常，fis.close() 仍会执行，且原始异常优先抛出；若 close() 也抛异常，会被抑制（suppressed），可通过 getSuppressed() 获取，不丢失主因。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
