不该。Java中用异常控制业务流程会模糊错误语义、降低性能、增加理解成本；仅当发生真正意外（如连接断开）或违反契约（如传null）时才用异常，其余应使用Result等明确返回类型封装状态。
异常该不该用来控制业务流程
不该。Java里用Exception或RuntimeException做正常分支跳转，会模糊错误语义、拖慢性能、增加调用方理解成本。比如把“用户不存在”抛UserNotFoundException，听起来合理，但实际它不是意外状况——这是常见查询结果，应该走返回值表达。
真正该用异常的场景只有两类：程序无法继续执行的意外（如数据库连接断开、磁盘满）、违反契约的非法输入（如传null进不允许为空的参数）。其余都建议用明确的返回类型封装状态。
用Optional还是自定义Result类
Optional适合简单场景，比如单个方法只可能成功或失败，且失败无需携带原因。但它不能序列化（JDK 8+虽支持但Jackson默认不处理），也不支持嵌套错误码或上下文信息。
更通用的做法是定义轻量Result类：
立即学习“Java免费学习笔记（深入）”；
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": "用户不存在"}
最难把握的是边界感：异常描述的是“系统出了什么问题”，返回值描述的是“这次请求的结果是什么”。一旦混淆，接口就变成靠猜才能用的东西。
