エラーおよび例外処理

このトピックでは、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" メンバーが使用されてバッファーのサイズを大きくします。

変更の始まりユーザー定義拡張機能は、必要なら、returnCode に非ヌル値を設定することにより、独自のエラー・リカバリーを実行できます。 ユーティリティー関数呼び出しはユーザー定義拡張機能に戻って、returnCode で状況を渡します。 何らかのユーティリティー関数で発生したすべての例外は、追加のエラー・リカバリーを実行するためにメッセージ・ブローカーに戻されなければなりません (すなわち、returnCode で CCI_EXCEPTION が戻された場合)。 これは、ユーザー定義拡張機能が独自のエラー処理を完了した後に cciRethrowLastException を呼び出すことによって行います。cciRethrowLastException を呼び出すと、C インターフェースは最後の例外を再スローし、これをメッセージ・ブローカーの他の層によって処理できるようにします。 この場合、C exit 呼び出しと同様、cciRethrowLastException が戻されないことに注意してください。変更の終わり

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

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

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

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

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