受检 vs 非受检异常：设计哲学与选型

// 底层方法：明确声明"我可能抛出 IOException"
public String readConfig(String path) throws IOException {
    return new String(Files.readAllBytes(Paths.get(path)));
}

// 中层调用者：必须面对 IOException，不能假装成功
public AppConfig loadConfig() throws IOException {
    String raw = readConfig("/etc/app.conf");
    return AppConfig.parse(raw);
}

// 顶层调用者：最终必须处理（try-catch）或继续声明
public void startup() {
    try {
        AppConfig config = loadConfig();
        // 安全地使用 config...
    } catch (IOException e) {
        logger.error("配置加载失败，使用默认配置", e);
        config = AppConfig.defaults();
    }
}

// DAO 层：不再声明受检异常
@Repository
public class UserDao {
    public User findById(Long id) {
        // Spring 自动把 SQLException 转换为 DataAccessException（非受检）
        return jdbcTemplate.queryForObject(
            "SELECT * FROM users WHERE id = ?",
            new UserRowMapper(), id);
    }
}

// Service 层：不需要 throws 声明，代码干净
@Service
public class UserService {
    public User getUser(Long id) {
        return userDao.findById(id);  // 异常自动向上传播
    }
}

// Controller 层：全局异常处理器统一兜底
@RestControllerAdvice
public class GlobalExceptionHandler {
    @ExceptionHandler(DataAccessException.class)
    public ApiResponse handleDbError(DataAccessException e) {
        return ApiResponse.error("数据库操作失败", e.getMessage());
    }
}

/* ─── 第一步：定义错误码枚举 ─── */
public enum ErrorCode {
    USER_NOT_FOUND(404, "用户不存在"),
    DUPLICATE_EMAIL(409, "邮箱已被注册"),
    DB_ERROR(500, "数据库操作失败");

    final int httpStatus;
    final String message;
    ErrorCode(int s, String m) { httpStatus = s; message = m; }
}

/* ─── 第二步：自定义非受检业务异常 ─── */
public class BusinessException extends RuntimeException {
    private final ErrorCode code;

    public BusinessException(ErrorCode code) {
        super(code.message);
        this.code = code;
    }

    public BusinessException(ErrorCode code, Throwable cause) {
        super(code.message, cause);  // 保留原始异常链
        this.code = code;
    }
}

/* ─── 第三步：在边界处包装受检异常 ─── */
public User findUser(Long id) {
    try {
        return userDao.findById(id)
            .orElseThrow(() -> new BusinessException(ErrorCode.USER_NOT_FOUND));
    } catch (DataAccessException e) {
        // 受检异常 → 非受检异常，保留原始 cause
        throw new BusinessException(ErrorCode.DB_ERROR, e);
    }
}

/* ─── 模式 1：Optional 替代"查不到就抛异常" ─── */
Optional<User> user = userRepository.findById(1L);
user.ifPresent(u -> sendEmail(u));

/* ─── 模式 2：CompletableFuture 的异常处理 ─── */
CompletableFuture.supplyAsync(() -> fetchFromRemote())
    .thenApply(data -> process(data))
    .exceptionally(ex -> {           // 统一处理异步异常
        log.error("异步任务失败", ex);
        return fallbackValue;
    });

/* ─── 模式 3：自定义 Result 类型（Kotlin 风格）─── */
public sealed interface Result<T> {
    record Success<T>(T value) implements Result<T> {}
    record Failure<T>(Throwable error) implements Result<T> {}
}

// 使用：返回 Result 而不是抛异常
public Result<User> findUser(Long id) {
    try {
        return new Result.Success<>(dao.findById(id));
    } catch (SQLException e) {
        return new Result.Failure<>(e);
    }
}

// Q1: 受检异常和非受检异常的区别？
// 答：继承关系 + 编译器是否强制处理 + 语义（外部问题 vs 编程错误）

// Q2: @Transactional 默认对哪些异常回滚？
// 答：只对 RuntimeException 和 Error 回滚
//     受检异常（IOException 等）不回滚 —— 这是经典陷阱
//     解决：@Transactional(rollbackFor = Exception.class)

// Q3: Spring 为什么用 RuntimeException？
// 答：消除样板代码 + 支持全局异常处理 + 兼容事务回滚

// Q4: 你项目中如何处理异常？
// 答：自定义非受检 BusinessException + ErrorCode 枚举
//     + @RestControllerAdvice 全局处理器 + 统一 JSON 响应格式

// Q5: 受检异常还有存在的意义吗？
// 答：有。SDK 开发、安全关键系统、边界明确的 API（如 InterruptedException）
//     承认设计初衷好，但指出在企业 Web 开发中非受检异常更实用