如何利用throws将底层异常透传给上层控制器统一处理-java教程-PHP中文网

throws本身不能透传异常，真正实现异常交由@controlleradvice处理的是不捕获、不处理、直接抛出异常的行为；需确保service层不吞异常、controller层不拦截运行时异常、全局处理器覆盖对应异常类型，并对检查型异常显式声明throws。

如何利用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("系统异常"));
    }
}
</result></result></result>

确保异常类型匹配、顺序合理（子类优先于父类），否则可能被更宽泛的 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()));
    }
}
</result>

本质上，throws 是 Java 的语法契约，它让检查型异常“合法上浮”；而 Spring 的异常处理机制则负责在 Controller 层之后接手这些冒上来的异常。真正起作用的不是 throws 关键字本身，而是整个调用链上不拦截、不消化、不掩盖异常的行为模式。