エラー処理 (RPC)
同期 RPC では、クライアントは成功コードまたは失敗コードを使用して を返すリモート呼び出しを行います。 非同期 RPC を使用すると、呼び出しが失敗する機会が増え、発生する場所とタイミングに応じて、これらのエラーの処理方法が異なります。 次の表では、呼び出しが失敗する方法と、その処理方法について説明します。
クライアント側のクリーンアップ
障害の症状 | クリーンアップ |
---|---|
クライアントは、リモート プロシージャを呼び出すときに例外をキャッチします。 | RPC API 呼び出しは必要ありません。 すべての RPC 状態がクリーンアップされました。 |
クライアントは通話完了通知を受け取りますが、 RpcAsyncCompleteCall を呼び出すとエラー コードを受け取ります。 | RPC API 呼び出しは必要ありません。 すべての RPC 状態がクリーンアップされました。 |
クライアントは、非中止または中止キャンセルを発行します。 | クライアントは通知を待機し、通知が到着したら RpcAsyncCompleteCall を 呼び出す必要があります。 |
サーバー側のクリーンアップでは、重要な概念がハンドオフ ポイントです。 非同期呼び出しのサーバー側の処理中、通常、一部の処理は呼び出しを受信したスレッド ( ディスパッチャー スレッドとも呼ばれます) で実行され、必要に応じてディスパッチャー スレッドはメモリ ブロックに十分な状態を設定し、呼び出しの処理を続行するために別のスレッド ( ワーカー スレッドとも呼ばれます) に通知します。 ディスパッチャー スレッドがワーカー スレッドが ハンドオフ ポイントと呼ばれることを正常に通知する瞬間。
サーバー側のクリーンアップ
エラーが発生しました | クリーンアップ |
---|---|
ハンドオフポイントの前。 | 例外をスローします。 RpcAsyncCompleteCall の呼び出しは必要ありません。 |
ハンドオフ ポイントの後。 | RpcAsyncAbortCall を呼び出すか、エラーが致命的ではなく、クライアントに結果を返すことができる場合は RpcAsyncCompleteCall を呼び出します。 RpcAsyncCompleteCall 関数の呼び出しが失敗した場合、RPC ランタイムはパラメーターを解放します。 ユーザーは、これらのパラメーターにアクセスできません。 ディスパッチャー スレッドは、呼び出しを安全に中止できないため、ハンドオフポイント後に失敗する可能性のある実質的な処理を実行しないでください。 具体的には、ハンドオフ ポイントの後に例外をスローしたり、サーバーがクラッシュしたりする可能性があります。 |
パイプの特殊なエラー処理ケース
パイプを使用する場合、エラー処理には特別なケースがあります。 次の一覧では、エラーの原因とエラーの処理方法について説明します。
エラーの原因 | 処理方法 |
---|---|
クライアントはプッシュを呼び出し、呼び出しは失敗します。 | RPC API 呼び出しは必要ありません。 すべての RPC 状態がクリーンアップされました。 |
クライアントは、in パイプがドレインされる前に RpcAsyncCompleteCall を呼び出します。 | 適切なパイプ入力エラー コードで呼び出しが失敗します。 |
クライアントは pull を呼び出し、呼び出しは失敗します。 | RPC API 呼び出しは必要ありません。 すべての RPC 状態がクリーンアップされました。 |
クライアントまたはサーバーのどちらかが、間違った順序でプッシュまたはプルを呼び出します。 | 実行時は、パイプ充填エラーの状態を返します。 |
サーバーはプッシュまたはプルを呼び出し、呼び出しは失敗します。 | Push はエラー コードを返します。 RpcAsyncCompleteCall の呼び出しは必要ありません。 |
サーバーは、パイプがドレインされる前に RpcAsyncCompleteCall を 呼び出します。 | パイプ呼び出しは、パイプの充填エラー状態を返します。 |
ディスパッチ後、受信操作は失敗します。 | 次にサーバーが pull を呼び出してパイプ データを受信すると、エラーが返されます。 |