微服务-基于Grpc的进程通信-Grpc异常捕获RpcException(4-4)
在Grpc的实际使用中,需要对Grpc的异常进行封装,在架构时发现,客户端中正常的Exception无法捕获到在Grpc服务端抛出的异常,经过仔细排查问题得到解决,记录下便于查漏补缺
代码结构如下:其中GrpcClientAPi为客户端,GrpcServer为服务端。
![](https://img2020.cnblogs.com/blog/783110/202111/783110-20211101150730756-714281344.png)
首先在ProtobufNet中自定义一个ApiException类,继承自Exception
![](https://img2020.cnblogs.com/blog/783110/202111/783110-20211101150804684-2013321111.png)
在GrpcClientApi中定义了中间件LogRequestMiddleware用于捕获异常。如果抛出了ApiException异常,则会被我们捕获
(1)ApiException实例测试:
客户端GrpcClientAPi:
![](https://img2020.cnblogs.com/blog/783110/202111/783110-20211101152029855-754275441.png)
中间件LogRequestMiddleware:
![](https://img2020.cnblogs.com/blog/783110/202111/783110-20211101152119197-1557257055.png)
结果:
![](https://img2020.cnblogs.com/blog/783110/202111/783110-20211101152147303-28579386.png)
然而,在服务端GrpcServer抛出ApiException异常,中间件无法拦截具体的错误信息
(2)ApiException在Grpc的实例测试
客户端GrpcClientAPi:
![](https://img2020.cnblogs.com/blog/783110/202111/783110-20211101152230731-1927306353.png)
服务端GrpcServer:
中间件不变,结果如下:
![](https://img2020.cnblogs.com/blog/783110/202111/783110-20211101152355276-1530370851.png)
无法捕获到自定义的异常。于是去官网搜了下rpc异常的相关资料,RpcException特地用于在rpc中进行异常处理。
(3)RpcException测试
客户端GrpcClientAPi不变
服务端GrpcServer:
![](https://img2020.cnblogs.com/blog/783110/202111/783110-20211101152558179-593072941.png)
中间件添加对RpcException的捕获:
![](https://img2020.cnblogs.com/blog/783110/202111/783110-20211101152632209-1781358959.png)
结果:
![](https://img2020.cnblogs.com/blog/783110/202111/783110-20211101152716504-231618756.png)
(4)Exception测试
结果:
![](https://img2020.cnblogs.com/blog/783110/202111/783110-20211101152746957-2048521959.png)
总结:
在Grpc中,自定义的Exception(本文以ApiException为例),无法被显示识别,除了官方提供的RpcException,但奇怪的是ApiException和RpcExceprion都继承自Exception。
猜测应该在返回结果时统一对Grpc的异常通过RpcException重新进行过处理。
以上,仅用于学习和总结