gRPC开发中exceptionally回调未执行、返回UNKNOWN状态码的异常处理问题

• 异常抛出逻辑和CompletionStage的回调机制完全错位：GetNamesService#getNames方法是同步直接抛出运行时异常，不是返回携带异常状态的CompletionStage实例。
• 代码执行到getNamesService.getNames(request)这一行时，方法还没返回CompletionStage对象，异常就已经直接抛出，后续链式调用的thenAccept、exceptionally根本没有机会被构建、触发。
• 这个同步抛出的异常会直接被gRPC服务端框架的默认拦截逻辑捕获，走统一的未知异常转译流程，将无自定义处理的异常映射为UNKNOWN状态码，既不会执行你写在exceptionally块里的打印语句，也无法透传你自定义的INVALID_ARGUMENT状态码。

调整业务方法的异常返回逻辑（推荐） #

把GetNamesService里同步抛异常的写法，改为返回携带异常的已完成异步Stage，让异常进入Stage的正常回调链路：

public CompletionStage<NameResponse> getNames(NameRequest request) {
  // 返回异常完成的Stage，而非同步直接抛错
  return CompletableFuture.failedStage(
    Status.INVALID_ARGUMENT
      .withDescription("Invalid request")
      .asRuntimeException()
  );
}

这种写法下，方法会正常返回CompletionStage实例，后续的exceptionally回调会被正常触发，自定义的错误状态码可以正确透传到客户端。

增加同步执行段的异常捕获 #

如果业务逻辑确实可能在同步执行阶段抛出异常，需要在调用getNamesService.getNames的位置加try-catch，接住同步抛出的异常，不能完全依赖CompletionStage的异步异常回调处理所有错误：

@Override
public void getNames(NameRequest request, StreamObserver<NameResponse> responseObserver) {
  CompletionStage<NameResponse> stage;
  try {
    stage = getNamesService.getNames(request);
  } catch (Throwable t) {
    // 直接处理同步段抛出的异常
    responseObserver.onError(handleException(t));
    return;
  }

  stage
   .thenAccept(r -> {
      responseObserver.onNext(r);
      responseObserver.onCompleted();
   })
   .exceptionally(t -> {
      System.out.println("About to handle the exception");
      responseObserver.onError(handleException(t));
      // exceptionally要求返回同类型值，错误处理完成后返回null即可
      return null;
   });
}

补充注意：原代码的exceptionally lambda未返回对应类型的值，本身会触发CompletionStage的类型校验异常，补充返回值后才能保证回调逻辑正常执行。

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