throws本身不能透传异常，真正实现异常交由@ControllerAdvice处理的是不捕获、不处理、直接抛出异常的行为；需确保service层不吞异常、controller层不拦截运行时异常、全局处理器覆盖对应异常类型，并对检查型异常显式声明throws。
在 Spring Boot 中，throws 本身不能“透传”异常给上层控制器统一处理——它只是声明方法可能抛出检查型异常（checked exception），而真正实现异常向上冒泡、最终交由全局异常处理器（如 @ControllerAdvice）捕获的，是不捕获、不处理、直接抛出异常这一行为。关键在于：让底层服务抛出的异常原样到达 Controller 层，再由 Spring 的异常解析机制触发全局处理器。
1. 不要在 service 或 dao 层吞掉或转换底层异常
常见错误是用 try-catch 捕获后“静默处理”或转成无关异常，导致原始堆栈和类型丢失：
// ❌ 错误示例：吃掉 SQLException，丢失上下文
public void updateUser(User user) {
try {
userMapper.update(user);
} catch (SQLException e) {
log.error("更新失败", e); // 仅打日志，没抛出
// 缺少 throw → 异常终止于此，Controller 收不到
}
}
✅ 正确做法：声明 throws SQLException，并让异常自然向上抛：
// ✅ 正确示例：声明并透传
public void updateUser(User user) throws SQLException {
userMapper.update(user); // MyBatis 底层可能抛 SQLException
}
注意：Spring 的 JdbcTemplate 或 MyBatis 默认会将 SQLException 包装为 DataAccessException（运行时异常），所以实际中更常见的是直接抛出 RuntimeException 子类，无需 throws 声明。但若你使用了原生 JDBC 或某些老框架，throws 就有必要。
2. Controller 层不捕获，也不声明 throws（对运行时异常）
对于 RuntimeException 及其子类（如 DataAccessException、IllegalArgumentException），Controller 方法无需加 throws，也不应 try-catch 后吞掉：
// ✅ 让异常自然冒出，交给 @ControllerAdvice 处理
@PostMapping("/users")
public Result update(@RequestBody User user) {
userService.updateUser(user); // 若此处抛 DataAccessException，直接向上跑
return Result.success();
}
Spring MVC 会自动拦截未被捕获的运行时异常，并查找匹配的 @ExceptionHandler 方法。
3. 全局异常处理器要覆盖底层异常类型
@ControllerAdvice 中的 @ExceptionHandler 必须能捕获到底层抛出的具体异常（或其父类）：
@ControllerAdvice
public class GlobalExceptionHandler {
// ✅ 捕获 MyBatis/JDBC 抛出的数据访问异常
@ExceptionHandler(DataAccessException.class)
public ResponseEntity<Result> handleDataAccessException(DataAccessException e) {
log.warn("数据访问异常", e);
return ResponseEntity.status(500).body(Result.fail("数据库操作失败"));
}
// ✅ 也可捕获更底层的 SQLException（如果真有）
@ExceptionHandler(SQLException.class)
public ResponseEntity<Result> handleSqlException(SQLException e) {
return ResponseEntity.status(500).body(Result.fail("SQL 执行异常"));
}
// ✅ 统一兜底所有未明确处理的运行时异常
@ExceptionHandler(RuntimeException.class)
public ResponseEntity<Result> handleRuntime(RuntimeException e) {
return ResponseEntity.status(500).body(Result.fail("系统异常"));
}
}
确保异常类型匹配、顺序合理（子类优先于父类），否则可能被更宽泛的 handler 提前拦截。
4. 对检查型异常（Checked Exception）需显式 throws + controller 声明
如果你坚持用 checked exception（如自定义 BusinessException extends Exception），那么：
- Service 方法必须声明
throws BusinessException - Controller 方法也必须声明
throws BusinessException（否则编译不通过） -
@ExceptionHandler才能捕获到它（Spring 支持捕获 checked exception）
@Service
public class UserService {
public void updateUser(User user) throws BusinessException {
if (user.getId() == null) {
throw new BusinessException("用户ID不能为空");
}
userMapper.update(user);
}
}
@RestController
public class UserController {
@PostMapping("/users")
public Result update(@RequestBody User user) throws BusinessException {
userService.updateUser(user); // 必须声明 throws，否则编译报错
return Result.success();
}
}
@ControllerAdvice
public class GlobalExceptionHandler {
@ExceptionHandler(BusinessException.class)
public ResponseEntity<Result> handleBiz(BusinessException e) {
return ResponseEntity.badRequest().body(Result.fail(e.getMessage()));
}
}
本质上，throws 是 Java 的语法契约，它让检查型异常“合法上浮”；而 Spring 的异常处理机制则负责在 Controller 层之后接手这些冒上来的异常。真正起作用的不是 throws 关键字本身，而是整个调用链上不拦截、不消化、不掩盖异常的行为模式。
