Java Optional.orElseThrow 如何保留业务错误：异常类型、消息来源与空值边界

用户详情接口最怕把“查不到”变成一串没有上下文的 NoSuchElementException。在 Java 里，Optional.orElseThrow 可以把空结果明确地转换成业务异常；关键不在于把它写进每个链式调用，而在于先决定异常类型、消息来源和边界由哪一层负责。

查询结果必须为空时，优先使用 orElseThrow(() -> new UserNotFoundException(userId))；只有确实接受默认的 NoSuchElementException 时，才使用无参数重载。

从 userId 到 User：先看查询结果经过了什么

假设仓储层的方法是 findById(long userId)，返回 Optional。这一步已经把“有记录”和“没有记录”编码进返回值，服务层不需要再用一个额外的布尔字段猜测状态。

public User loadUser(long userId) {
    return userRepository.findById(userId)
            .orElseThrow(() -> new UserNotFoundException(userId));
}

这里的路径很短：userId 进入 findById，结果装在 Optional 中，再由 orElseThrow 决定返回 User 还是抛出异常。服务层因此保留了业务含义，控制器可以把 UserNotFoundException 映射成 404。

两个重载的差别：异常由谁命名

默认重载适合边界已经足够清楚的内部代码

User user = cache.get(userId).orElseThrow();

无参数版本在空值时抛出 NoSuchElementException。它的优点是简洁，但异常消息没有业务标识；如果调用方要区分“用户不存在”和“缓存数据损坏”，这个选择就太粗了。

Supplier 重载把业务上下文放进异常

User user = userRepository.findById(userId)
        .orElseThrow(() -> new UserNotFoundException(userId));

Supplier 只在 Optional 为空时调用，所以异常对象不会在成功路径提前构造。更重要的是，UserNotFoundException 直接携带 userId，日志和接口错误处理不必从一段字符串里反推对象。

异常消息和空值边界怎么落到代码

异常类可以保持很小，让调用方负责决定 HTTP 或消息队列语义：

public final class UserNotFoundException extends RuntimeException {
    private final long userId;

    public UserNotFoundException(long userId) {
        super("user not found: " + userId);
        this.userId = userId;
    }

    public long userId() {
        return userId;
    }
}

不要把 orElseThrow 写成 orElseThrow(new UserNotFoundException(userId))：这个重载需要的是异常供应器，而不是已经创建好的异常。也不要用 orElse(null) 把问题推迟到更远的调用点，否则堆栈位置和错误对象都会变差。

用三组测试核对结果，而不是只看编译通过

@Test
void returnsUserWhenPresent() {
    User user = service.loadUser(7L);
    assertEquals(7L, user.id());
}

@Test
void throwsWithUserIdWhenMissing() {
    UserNotFoundException ex = assertThrows(
            UserNotFoundException.class, () -> service.loadUser(9L));
    assertEquals(9L, ex.userId());
    assertEquals("user not found: 9", ex.getMessage());
}

@Test
void defaultOverloadUsesNoSuchElementException() {
    assertThrows(NoSuchElementException.class,
            () -> Optional.empty().orElseThrow());
}

第一组确认命中路径原样返回 User；第二组确认业务异常携带 userId；第三组把默认重载的契约固定下来。这样以后有人把业务查询改回无参数版本，测试会直接暴露语义退化。

常见问题

orElseThrow 和 get 有什么区别？

两者在空值时都可能得到 NoSuchElementException，但 Java API 更推荐用 orElseThrow() 表达“这里必须有值”，也可以自然切换到带异常供应器的重载。

异常供应器会在成功时执行吗？

不会。只有 Optional 为空时，Supplier 才会生成异常；因此可以把异常构造放在 lambda 中。

Optional 变量能不能直接设为 null？

不应该。查询没有结果应使用 Optional.empty()；一个本身为 null 的 Optional 会让调用方在调用 orElseThrow 前就触发空指针。

小结

orElseThrow 的价值是把查询边界说清楚：命中时返回实体，未命中时交给明确的异常类型。内部缓存读取可以接受默认重载，跨越业务边界的查询更适合带 Supplier 的版本，并用测试锁定异常类型、消息和标识符。