Java Optional orElse()抛出异常时无法返回备选值问题咨询

异常和orElse()、orElseGet()的选型没有任何关系。核心原因是主流ORM框架（比如Spring Data JPA、MyBatis-Plus的通用findById实现）的findById方法本身不允许传入null作为主键参数，当你传入null时，框架会在执行数据库查询前直接抛出参数校验异常，根本走不到后续的Optional分支逻辑，自然不会触发你预期的默认值返回。
你提出的先判断id非空再查询的思路方向完全正确，只是可以做简化优化，避免冗余代码。

首先明确：直接替换orElse()为orElseGet()、ifPresentOrElse()都解决不了问题，因为异常发生在findById()方法调用的瞬间，这些Optional处理方法根本没有执行机会。

方案1：Optional链式写法（推荐，最简洁） #

把id的空判断纳入Optional链路，从根源上避免传null给DAO层，同时减少不必要的对象创建：

Employee employee = Optional.ofNullable(request.getId())
        .flatMap(employeeRepository::findById)
        .orElseGet(Employee::new);

逻辑说明：

• 用Optional.ofNullable()包装可能为null的id，如果id为null，直接返回空Optional，不会执行后续的数据库查询逻辑
• 用flatMap而非map处理Repository返回的结果，是因为findById本身已经返回Optional<Employee>，用map会产生Optional<Optional<Employee>>的嵌套结构，flatMap可以直接把嵌套的Optional拍平
• 用orElseGet(Employee::new)替代orElse(new Employee())是更优实践：只有真的需要返回默认值（id为null、或者查询无结果）时才会创建Employee实例，不会像orElse()那样，哪怕已经查到了员工数据，也会提前创建一个完全用不上的默认Employee对象，减少无意义的性能开销。

方案2：优化后的if判空写法（可读性强） #

你原本写的if逻辑完全合理，只需要稍作调整避免重复创建默认对象即可，适合团队对Optional流式写法接受度不高的场景，逻辑直白没有理解门槛：

Employee employee;
if (request.getId() == null) {
    employee = new Employee();
} else {
    employee = employeeRepository.findById(request.getId())
                   .orElseGet(Employee::new);
}

不要为了省事修改Repository层的findById实现，让它接受null参数、返回空Optional。这种做法违背了Spring Data等框架的接口约定，后续其他代码调用findById时很容易因为默认预期不一致埋下隐患，参数合法性校验应该在DAO层调用之前完成。

内容的提问来源于stack exchange，提问作者user19254373