例外処理 (RPC)

RPC では、Windows API と同じ方法で例外処理が使用されます。

RpcTryFinally / RpcFinally / RpcEndFinally 構造体は、Windows try-finally ステートメントと同じです。 RPC 例外コンストラクト RpcTryExcept / RpcExcept / RpcEndExcept は、Windows try-except ステートメントと同じです。

RPC 例外ハンドラーを使用する場合、クライアント側のソース コードは移植可能です。 プラットフォームごとに提供される異なる RPC ヘッダー ファイルによって、各プラットフォームの RpcTry マクロと RpcExcept マクロが解決されます。 Windows 環境では、これらのマクロは Windows try-finally ステートメントと try-except ステートメントに直接マップされます。 他の環境では、これらのマクロは、例外ハンドラーの他のプラットフォーム固有の実装にマップされます。

これらの構造体によって発生する可能性のある例外には、RPC 関数によって返される一連のエラー コードと、RPC_S_とRPC_Xプレフィックス、および Windows によって返される例外のセットが含まれます。 詳細については、「 RPC 戻り値」を参照してください。

RpcTry マクロと RpcExcept マクロは、カスタマイズ可能なプラットフォームに依存しない方法で例外を処理しますが、Windows Vista 以降のバージョンの Windows では、RpcExceptionFilter が例外を処理する推奨される方法です。 最も一般的な構造化例外の多くをキャプチャするためにカスタム フィルターを記述する必要はありません。ただし、カスタム例外フィルターには RpcExcept が引き続き必要です。

サーバー アプリケーション、サーバー スタブ、およびサーバー ランタイム ライブラリ (トランスポート層の上) で発生する例外は、クライアントに反映されます。 サーバー トランスポート レベルから例外は反映されません。 サーバー ルーチンが RPC ランタイムにエラーを返すには、例外をスローすることをお勧めします。 サーバー ルーチンは、サーバー ルーチン間のエラーの通信に適した任意のメソッドを使用できますが、リモート プロシージャの実行を妨げるエラーが発生した場合は、サーバー ルーチンのみがエラーとして認識する値を RPC に返すのではなく、クリーンアップ後および RPC ランタイムに戻る前に例外を発生させる必要があります。

次の図は、サーバーからクライアントに例外が返される方法を示しています。

RPC 例外ハンドラーは、Open Software Foundation-Distributed Computing Environment (OSF-DCE) 例外処理マクロ TRY、 FINALLY、 CATCH とは若干異なります。 さまざまなベンダーは、OSF-DCE RPC 関数を Microsoft RPC 関数にマップするファイル ( TRY、 CATCH、 CATCH_ALL、 ENDTRY など) を提供しています。 これらのヘッダー ファイルは、RPC_S_* エラー コードを OSF-DCE 例外に対応する rpc_s_* にマップし、RPC_X_* エラー コードを rpc_x_* にマップします。 OSF-DCE の移植性を高めるには、これらのインクルード ファイルを使用します。 RPC 例外ハンドラーの詳細については、「 RpcExceptionFilter、 RpcExcept、 RpcFinally」を参照してください。 Windows 例外ハンドラーの詳細については、「 構造化例外処理」を参照してください。