怎么通过 Optional.orElseThrow() 在值为空时抛出自定义的业务逻辑异常以中断流程

Optional.orElseThrow() 通过 Supplier 延迟创建并抛出业务异常，精准中断流程；应优先用 Lambda 动态构造含上下文的异常，避免复用或提前捕获，确保语义明确、诊断信息完整。

说白了，就是在 Optional 为空的时候，直接扔一个你自定义的业务异常出去，流程到此为止。怎么做？传一个 Supplier 进去就行了，异常由 Supplier 的 get() 方法产生。

传入 Lambda 创建具体异常

最常见的套路——用 Lambda 表达式现场捏一个异常实例：

userOpt.orElseThrow(() -> new UserNotFoundException("用户ID " + userId + " 未找到"));

这里有几个关键点：

• 异常类型推荐用自定义的运行时异常（比如 UserNotFoundException），不用显式写 try-catch，语义上就是“业务中断”。
• Lambda 是延迟执行的——只有当 Optional 真的为空时才会触发，不会平白无故创建对象，性能也放心。

复用已有异常实例（慎用）

如果异常对象不含动态参数，倒是可以提前创建好，然后反复用：

final UserNotFoundException notFound = new UserNotFoundException("用户不存在");
userOpt.orElseThrow(() -> notFound);

但有两条雷区：

• 千万别手滑写成 orElseThrow(notFound)——方法签名要的是 Supplier，不是对象本身，编译都不通过。
• 一旦异常里带了动态上下文（比如用户 ID、时间戳），复用就会丢失这些诊断信息，出了问题不好排查。所以这种做法只适合极简场景。

配合业务校验链使用

很多时候 Optional 不是孤零零用的，后面还跟着 filter 之类的操作。这时候 orElseThrow 就能和它们串成一条流畅的空值防护链：

return userOpt.filter(User::isActive)
               .orElseThrow(() -> new InvalidUserException("用户已停用或不存在"));

先 filter 再 orElseThrow，抛出的异常语义更精准——“找到了，但不可用”和“根本没找到”是两回事。另外，既然用了 orElseThrow，后面就不要再做 if 判空或者 isPresent() 检查了，那等于白用 Optional。

不要和 try-catch 混用做流程控制

除非上层真的需要捕获并转换异常类型，否则别在 orElseThrow 外面包一层 try-catch。来看反例和正例：

• ❌ 错误示范：

  try { return opt.orElseThrow(...); } catch (UserNotFoundException e) { throw new ServiceException(e); }

• ✅ 正确做法：让异常自然往上冒泡，由统一的异常处理器（比如 Spring 的 @ControllerAdvice）统一处理响应格式。
• 业务异常的设计初衷就是中断当前流程，强行 catch 再换一个异常抛出去，反而模糊了错误边界，后续维护成本也跟着涨。