17370845950

不该。Java中用异常控制业务流程会模糊错误语义、降低性能、增加理解成本；仅当发生真正意外（如连接断开）或违反契约（如传null）时才用异常，其余应使用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手动拼HTTP状态码——破坏了业务逻辑与协议层的分离
• 在service层抛异常，靠@ControllerAdvice全局捕获并转成统一JSON——掩盖了哪些方法实际会失败，导致接口文档和实现脱节

推荐做法：

• Service方法返回Result，明确表达“这个操作可能不成功”
• Controller只做薄包装：检查Result.isSuccess()，决定返回200 OK还是400 Bad Request，错误体直接用Result的errorCode和message
• 前端拿到的JSON结构始终一致：{"success": false, "errorCode": "USER_NOT_FOUND", "message": "用户不存在"}

最难把握的是边界感：异常描述的是“系统出了什么问题”，返回值描述的是“这次请求的结果是什么”。一旦混淆，接口就变成靠猜才能用的东西。