エラーおよび例外処理

このトピックでは、C プログラミング言語で WebSphere Message Broker のユーザー定義拡張機能を開発する際に 考慮する必要のあるエラーおよび例外処理に関連する問題を扱います。Java プログラミング言語を使用してユーザー定義拡張機能を開発している場合、 標準 Java エラーおよび例外処理メソッドを使用できます。 例えば、WebSphere Message Broker が内部的に例外をスローする場合、 クラス MbException の Java 例外が使用可能になります。

エラーおよび例外の訂正処理は、正しいブローカー操作のために重要です。 ユーザー定義拡張機能が、エラーおよび例外を処理する方法および時期を意識し、 理解することが必要です。

メッセージ・ブローカーは、C++ 例外を生成してエラー条件を処理します。 これらの例外は、ブローカーの関連するソフトウェア層でキャッチされ、適切に処理されます。 しかし、C で作成されたプログラムは C++ プログラムをキャッチできず、 スローされる例外はすべて、デフォルトで C ユーザー定義の拡張コードを迂回し、 メッセージ・ブローカーの高位層でキャッチされます。

規則によると、ユーティリティー関数は、通常戻り値を使用して要求されるデータ、 例えばブローカー・オブジェクトのアドレスやハンドルを戻します。 戻り値は、障害が発生したことを示す場合があります。 例えば、ブローカー・オブジェクトのアドレスまたはハンドルが検索できなかった場合、 ゼロ (CCI_NULL_ADDR) が戻されます。 さらに、エラー状態の理由が戻りコード出力パラメーターに保管されます。 規則によると、このパラメーターはすべてのユーティリティー関数の関数プロトタイプの一部です。 ユーティリティー関数が正常に完了し、returnCode がヌルでない場合、 returnCode には CCI_SUCCESS が含まれます。 そうでない場合、以下に説明される戻りコードの 1 つが含まれます。 returnCode の値は、ユーティリティー関数が成功したかどうかを判別するため、 常に安全にテストされます。

ユーティリティー関数の呼び出しによってブローカーが例外を生成する場合、 returnCode パラメーターの値をそのユーティリティー関数に指定した場合のみ、 ユーザー定義拡張機能にこれが可視になります。 ヌル値が returnCode に指定され、例外が発生する場合、次のようになります。

これは、 ユーザー定義拡張機能が独自のエラー・リカバリーをどれも実行できないということです。 ただし、returnCode パラメーターが指定され、例外が発生する場合、 CCI_EXCEPTION の戻りコードが戻されます。 この場合、cciGetLastExceptionData または cciGetLastExceptionDataW (相違点は、cciGetLastExceptionDataW の戻すのが CCI_EXCEPTION_WIDE_ST である点。CCI_EXCEPTION_WIDE_ST には Unicode のトレース・テキストが入ることがあります。) を使用して、発生した例外のタイプの診断情報を取得することができます。 このデータは CCI_EXCEPTION_ST または CCI_EXCEPTION_WIDE_ST 構造に入れられて戻されます。

解放するリソースがない場合は、 ユーザー定義拡張機能で returnCode 引数を設定することを避けるようにお勧めします。 この引数を設定しないことによって、例外はユーザー定義拡張機能を迂回します。 その後これらの例外を、ブローカーによってより高位の WebSphere Message Broker スタックで処理できます。

メッセージ挿入は、CCI_EXCEPTION_ST 構造の CCI_STRING_ST メンバーで戻されます。 CCI_STRING_ST により、ユーザー定義拡張機能は必要な挿入を受け取るバッファーを提供できます。 ブローカーはデータをこのバッファーにコピーし、バイト出力の番号とデータの実際の長さを戻します。 バッファーの大きさが十分でないと、データはコピーされず、 必要なら "dataLength" メンバーが使用されてバッファーのサイズを大きくします。

ユーザー定義拡張機能は、必要ならどんなエラー・リカバリーでも実行できます。 CCI_EXCEPTION が戻された場合、すべての例外は、 追加のエラー・リカバリーを実行するためにメッセージ・ブローカーに戻されなければなりません。 これは、cciRethrowLastException を呼び出すことによって実行され、 その結果 C インターフェースは、 最後の例外がメッセージ・ブローカーの他の層によって処理できるように再スローします。

例外が発生し、ユーザー定義拡張機能によってキャッチされる場合、その拡張機能は cciGetLastExceptionDatacciGetLastExceptionDataW、または cciRethrowLastException 以外のユーティリティー関数を呼び出すことはできません。 他のユーティリティー関数を呼び出そうとすると、 ブローカーの保全性を妥協させる可能性のある予測不能な動作が発生します。

ユーザー定義拡張機能が重大なエラーを見つけた場合、cciThrowException または cciThrowExceptionW を使用して、メッセージ・ブローカーによって正しく処理される例外を生成することができます。 このような例外が生成され、 その例外が処理されない場合には、 提供される情報はシステム・ログ (syslog または Eventviewer) に書き込まれます。 トレースがアクティブな場合には、情報はブローカー・トレースにも書き込まれます。

例外およびブローカー動作のタイプ

ブローカーは、ユーザー定義拡張機能に公示できる例外のセットを生成します。これらの例外は、エラー条件が見つかったときにユーザー定義拡張機能によっても生成されます。 例外クラスは次のとおりです。

致命的
致命的例外は、ブローカー・プロセスが安全な実行を続行できなくなる条件が発生したか、 またはブローカー・ポリシーがプロセスを終了するときに生成されます。 致命的例外の例としては、重要なシステム・リソースの獲得失敗、 または内部的にキャッチされた重大なソフトウェア・エラーがあります。 ブローカー・プロセスは、致命的例外のスローに続いて終了します。
リカバリー可能
これらの例外は、自然に終了はしないものの、 現行メッセージ・フローの処理を終了する必要があることを意味するエラーに対して生成されます。 リカバリー可能例外の例としては、メッセージの内容の無効データ、 または出力ノードへのメッセージの書き込みの失敗などがあります。 リカバリー可能例外がスローされると、そのスレッド上の現行メッセージの処理は打ち切られますが、 スレッドはその入力ノードで実行を再開します。
構成
構成例外は、構成要求が失敗したときに発生します。 これは、構成要求のフォーマットのエラー、またはデータ中のエラーのためであると考えられます。 構成例外がスローされると、要求は拒否され、エラー応答メッセージが戻されます。
パーサー
メッセージ内容の解析またはビット・ストリームの作成を妨げる エラーに対して、メッセージ・パーサーにより生成されます。 パーサー例外は、ブローカーによってリカバリー可能例外として扱われます。
変換
別のデータ・タイプへの変換試行中に無効データが見つかった場合、 ブローカー文字変換機能によって生成されます。 変換例外は、ブローカーによってリカバリー可能例外として扱われます。
ユーザー
Throw ノードがユーザー定義例外をスローすると生成されます。
データベース
データベース管理システムが、ブローカー操作中にエラーを報告した場合に生成されます。 データベース例外は、ブローカーによってリカバリー可能例外として扱われます。
特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック
Copyright IBM Corporation 1999, 2006 Last updated: 5 01, 2006
as01430_