エラー処理

標準エラーモデル

コンセプトドキュメントと例で見たように、gRPC呼び出しが正常に完了すると、サーバーはクライアントに`OK`ステータスを返します（言語によっては、`OK`ステータスがコードで直接使用される場合と使用されない場合があります）。しかし、呼び出しが成功しなかった場合はどうなりますか？

エラーが発生した場合、gRPCは代わりにエラーステータスコードのいずれかを返します。オプションの文字列エラーメッセージには、発生した事象に関する詳細情報が提供されます。エラー情報は、サポートされているすべての言語のgRPCクライアントで利用できます。

リッチエラーモデル

上記のエラーモデルは公式のgRPCエラーモデルであり、すべてのgRPCクライアント/サーバーライブラリでサポートされており、gRPCデータ形式（プロトコルバッファなど）とは無関係です。お気づきかもしれませんが、これはかなり限定的であり、エラーの詳細を伝える機能は含まれていません。

ただし、データ形式としてプロトコルバッファを使用している場合は、こちらで説明されている、Googleによって開発および使用されているリッチエラーモデルの使用を検討することをお勧めします。このモデルにより、サーバーは1つ以上のprotobufメッセージとして表現された追加のエラー詳細を返し、クライアントはそれを消費できます。さらに、無効なパラメータ、クォータ違反、スタックトレースなど、最も一般的なニーズをカバーするための標準のエラーメッセージタイプのセットを指定しています。この追加のエラー情報のprotobufバイナリエンコーディングは、レスポンスのトレーリングメタデータとして提供されます。

このリッチエラーモデルは、C++、Go、Java、Python、およびRubyライブラリで既にサポートされており、少なくともgrpc-webおよびNode.jsライブラリには、それを要求する未解決の問題があります。他の言語ライブラリは、需要があれば将来的にサポートを追加する可能性があるため、興味がある場合はgithubリポジトリを確認してください。ただし、Cで記述されたgrpc-coreライブラリは、意図的にデータ形式に依存しないため、サポートされる可能性は低いことに注意してください。

プロトコルバッファを使用していない場合でも、同様のアプローチ（エラー詳細をトレーリングレスポンスメタデータに配置）を使用できますが、APIで実際に使用するには、このデータにアクセスするためのライブラリサポートを見つけるか、開発する必要があるでしょう。

ただし、このような拡張エラーモデルを使用するかどうかを決定する際には、以下の重要な考慮事項に注意する必要があります。

• 拡張エラーモデルのライブラリ実装は、エラー詳細ペイロードの要件と期待値に関して、言語間で一貫していない場合があります
• 既存のプロキシ、ロガー、およびその他の標準HTTPリクエストプロセッサは、エラー詳細を認識できないため、監視などの目的で活用できません
• トレーラーに追加のエラー詳細があると、ヘッドオブラインブロッキングが妨げられ、キャッシュミスの頻度が高くなるため、HTTP/2ヘッダー圧縮効率が低下します
• エラー詳細ペイロードが大きくなると、プロトコルの制限（最大ヘッダーサイズなど）に達する可能性があり、元のエラーが事実上失われます

エラーステータスコード

エラーは、ネットワーク障害から認証されていない接続まで、さまざまな状況でgRPCによって発生し、それぞれが特定のステータスコードに関連付けられています。次のエラーステータスコードは、すべてのgRPC言語でサポートされています。

一般的なエラー

ネットワーク障害

プロトコルエラー

言語サポート

標準エラーとリッチエラー詳細の処理方法に関するサンプルコードは、複数の言語で利用できます。

grpc-errorsリポジトリには、追加のエラー処理例も含まれています。