Java异常处理与返回值怎么平衡

从现在开始，我们要努力学习啦！今天我给大家带来《Java异常处理与返回值如何平衡》，感兴趣的朋友请继续看下去吧！下文中的内容我们主要会涉及到等等知识点，如果在阅读本文过程中有遇到不清楚的地方，欢迎留言呀！我们一起讨论，一起学习！

不该。Java中用异常控制业务流程会模糊错误语义、降低性能、增加理解成本；仅当发生真正意外（如连接断开）或违反契约（如传null）时才用异常，其余应使用Result等明确返回类型封装状态。

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

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

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

用Optional还是自定义Result类

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

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

public class Result<T> {
    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 <T> Result<T> success(T data) {
        return new Result<>(true, data, null, null);
    }

    public static <T> Result<T> 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