orElseGet中抛出的异常被UndeclaredThrowableException包装如何保留原异常类型

问题根因 #

该异常包装问题本质是Optional.orElseGet接收的Supplier函数式接口的get()方法未声明抛出任何受检异常，在orElseGet的lambda内部抛出受检类型的CustomException时，编译器/运行时会自动用UndeclaredThrowableException对原始异常做一层包装，规避函数式接口的方法签名限制。

可行解决方案 #

方案1：替换orElseGet为显式的存在性判断（最稳妥，无额外兼容问题） #

直接放弃lambda形式的orElseGet，先判断Optional是否有值，再走对应逻辑，完全绕开Supplier的异常限制，示例代码：

def function() throws CustomException {
  try {
    def membershipOpt = workspaceRepositoryService.getWorkspaceMembership(command.assigneeEmail, workspaceId)
    ProjectAssignment assignment
    if (membershipOpt.isPresent()) {
      assignment = createOrUndelete(membershipOpt.get(), project, command.assigneeRole, createdBy)
    } else {
      // 原orElseGet内部的逻辑直接放到此处即可
      Invitation invitation = workspaceService.inviteUserToWorkspace(command.assigneeEmail, workspace, createdBy)
      // 其余业务逻辑
    }
  } catch(Exception e) {
    throw e // 此处捕获到的直接是原始的CustomException
  }
}

方案2：调整CustomException为运行时异常（适合可以修改异常定义的场景） #

如果业务允许调整异常的继承结构，让CustomException继承RuntimeException而非Exception，变为非受检异常后就不会受Supplier的签名限制，orElseGet内部抛出时也不会被额外包装。

方案3：外层捕获时主动解包（适合不能改上游逻辑的场景） #

如果不想调整现有核心业务逻辑，可以在外层catch处加一层判断，遇到UndeclaredThrowableException时主动取出原始异常抛出：

def function() throws CustomException {
  try {
    // 原有的Optional.map.orElseGet逻辑保持不变
  } catch(Exception e) {
    if (e instanceof UndeclaredThrowableException) {
      Throwable realException = e.getUndeclaredThrowable()
      if (realException instanceof CustomException) {
        throw realException
      }
    }
    throw e
  }
}

内容的提问来源于stack exchange，提问作者Alex A.