错误处理
标准错误模型
正如你在我们的概念文件和例子中所看到的，当一个gRPC调用成功完成后，服务器会向客户端返回一个OK状态（根据语言的不同，OK状态可能会或可能不会直接用于你的代码中）。但是如果调用不成功会怎样呢？
如果发生了错误，gRPC会返回它的一个错误状态代码，同时还有一个可选的字符串错误信息，提供关于发生了什么的进一步细节。错误信息对所有支持的语言的gRPC客户端都可用。
更丰富的错误模型
上面描述的错误模型是官方的gRPC错误模型，被所有的gRPC客户端/服务器库所支持，并且与gRPC的数据格式（无论是协议缓冲区还是其他）无关。你可能已经注意到，它是相当有限的，不包括交流错误细节的能力。
然而，如果你使用协议缓冲区作为你的数据格式，你可能希望考虑使用谷歌开发和使用的更丰富的错误模型，如这里所述。这个模型使服务器能够返回并使客户端能够消费额外的错误细节，这些细节以一个或多个protobuf消息表示。它进一步指定了一套标准的错误消息类型，以涵盖最常见的需求（如无效参数、配额违规和堆栈跟踪）。这个额外的错误信息的protobuf二进制编码被作为响应中的尾部元数据提供。
这种更丰富的错误模型已经在C++、Go、Java、Python和Ruby库中得到支持，至少grpc-web和Node.js库有开放的问题要求它。如果有需求的话，其他语言库可能会在未来增加支持，如果有兴趣的话，请查看他们的github仓库。但是请注意，用C语言编写的grpc-core库可能永远不会支持它，因为它是特意与数据格式无关的。
如果你不使用协议缓冲区，你可以使用类似的方法（将错误细节放在尾部的响应元数据中），但你可能需要找到或开发库支持来访问这些数据，以便在你的API中实际使用它。
然而，在决定是否使用这样一个扩展的错误模型时，有一些重要的考虑因素需要注意，包括。
- 扩展错误模型的库实现在不同语言中对错误细节有效载荷的要求和期望可能不一致
- 现有的代理、记录器和其他标准的HTTP请求处理器对错误细节没有可见性，因此无法利用它们进行监控或其他目的。
- 拖车中的额外错误细节会干扰行头阻断，并且由于更频繁的缓存错过，会降低HTTP/2头的压缩效率。
- 较大的错误细节有效载荷可能会遇到协议限制（如最大头文件大小），有效地丢失原始错误。
错误状态代码
gRPC在各种情况下都会产生错误，从网络故障到未经认证的连接，每一种情况都与一个特定的状态代码有关。所有gRPC语言都支持以下错误状态代码。
一般错误
案例 状态代码
客户端应用程序取消了请求 GRPC_STATUS_CANCELLED
在服务器返回状态之前，最后期限已过 GRPC_STATUS_DEADLINE_EXCEEDED
服务器上没有找到方法 GRPC_STATUS_UNIMPLEMENTED
服务器正在关闭 GRPC_STATUS_UNAVAILABLE
服务器抛出了一个异常（或做了一些除了返回状态码以外的事情来终止RPC） GRPC_STATUS_UNKNOWN
网络故障
案例 状态代码
在截止日期前没有传输数据。也适用于在截止日期前传输了一些数据而没有发现其他故障的情况 GRPC_STATUS_DEADLINE_EXCEEDED
在连接中断之前，传输了一些数据（例如，请求元数据已经写入TCP连接） GRPC_STATUS_UNAVAILABLE
协议错误
案例 状态代码
无法解压但支持压缩算法 GRPC_STATUS_INTERNAL
客户端使用的压缩机制不被服务器支持 GRPC_STATUS_UNIMPLEMENTED
达到流控资源限制 GRPC_STATUS_RESOURCE_EXHAUSTED
违反流控协议 GRPC_STATUS_INTERNAL
解析返回状态错误 GRPC_STATUS_UNKNOWN
未经认证：获取元数据的凭证失败 GRPC_STATUS_UNAUTHENTICATED
权限元数据中设置了无效的主机 GRPC_STATUS_UNAUTHENTICATED
解析响应协议缓冲区时出错 GRPC_STATUS_INTERNAL
解析请求协议缓冲区时出错 GRPC_STATUS_INTERNAL
示例代码
关于说明如何处理各种gRPC错误的示例代码，请参阅grpc-errors repo。 使用www.DeepL.com/Translator翻译（免费版）