WebSphere Message Broker バージョン 8.0.0.5 オペレーティング・システム: AIX、HP-Itanium、Linux、Solaris、Windows、z/OS

製品の最新バージョンについては、IBM Integration Bus バージョン 9.0 をご覧ください。

エラーおよび例外処理

エラーおよび例外の訂正処理は、正しいブローカー操作のために重要です。 ユーザー定義拡張機能がエラーおよび例外を処理すべき方法および時期について考慮する必要があります。

ここでは、エラーおよび例外処理が、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 で状況を渡します。 ユーティリティー関数で発生した例外はすべて、追加のエラー・リカバリーを実行するためにブローカーに戻されなければなりません (すなわち、CCI_EXCEPTION が returnCode に戻された際)。 これは、ユーザー定義拡張機能が独自のエラー処理を完了した後に cciRethrowLastException を呼び出すことによって行います。 cciRethrowLastException を呼び出すと、C インターフェースは最後の例外を再スローし、これをブローカーの他の層によって処理できるようにします。 この場合、C exit 呼び出しと同様、cciRethrowLastException は戻されません。

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

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

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

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

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

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        最終更新:
        
        最終更新: 2015-02-28 17:48:00


概念トピック概念トピック | バージョン 8.0.0.5 | as01430_