Java异常处理与返回值怎么选

Java异常处理的核心在于严守边界：异常仅用于真正意外的系统故障或契约违反，绝不能替代业务流程控制；推荐用不可变的Result类统一封装操作结果，兼顾可读性、可序列化与错误信息丰富度，同时避免滥用受检异常和全局异常处理器，让接口语义清晰、调用方无需猜测——真正的健壮设计，始于对“错误”与“结果”的清醒区分。

异常该不该用来控制业务流程

不该。Java里用Exception或RuntimeException做正常分支跳转，会模糊错误语义、拖慢性能、增加调用方理解成本。比如把“用户不存在”抛UserNotFoundException，听起来合理，但实际它不是意外状况——这是常见查询结果，应该走返回值表达。

真正该用异常的场景只有两类：程序无法继续执行的意外（如数据库连接断开、磁盘满）、违反契约的非法输入（如传null进不允许为空的参数）。其余都建议用明确的返回类型封装状态。

用Optional还是自定义Result类

Optional适合简单场景，比如单个方法只可能成功或失败，且失败无需携带原因。但它不能序列化（JDK 8+虽支持但Jackson默认不处理），也不支持嵌套错误码或上下文信息。

更通用的做法是定义轻量Result类：

public class Result {
    private final boolean success;
    private final T data;
    private final String errorCode;
    private final String message;

    private Result(boolean success, T data, String errorCode, String message) {
        this.success = success;
        this.data = data;
        this.errorCode = errorCode;
        this.message = message;
    }

    public static  Result success(T data) {
        return new Result<>(true, data, null, null);
    }

    public static  Result failure(String errorCode, String message) {
        return new Result<>(false, null, errorCode, message);
    }
    // getter略
}

关键点：

• Result必须是不可变的（final字段 + 无setter）
• 不要在failure里塞Exception对象——调用方不该被迫处理堆栈
• 如果已有统一错误码体系，errorCode应直接对应枚举，而非字符串硬编码

接口方法签名里要不要声明throws

要谨慎。声明throws IOException这类受检异常（checked exception），等于强制所有调用方处理——哪怕它只是透传。这会导致大量模板代码，尤其在链式调用或函数式编程中（如Stream.map()里根本没法写try-catch）。

现代Java接口设计倾向：

• 受检异常只保留在底层IO、NIO、XML解析等真正无法绕过的场景
• 业务层统一转为运行时异常（RuntimeException子类），但保证有明确类型（如InsufficientBalanceException）和完整构造器（含error code、message、cause）
• 如果必须暴露异常语义给调用方，优先用返回值（Result）代替throws

REST API接口返回结构怎么映射到Java方法

别让Controller方法直接返回String或Map。Spring MVC能自动序列化Result为JSON，前提是它符合Jackson默认规则（getter、无参构造、不可变字段）。

典型反例：

• 用ResponseEntity