例外リスト・ツリーは、メッセージ・フローがメッセージを処理する際に発生する例外に関する情報を書き込む、論理メッセージ・ツリーの一部です。
例外リスト・ツリーのルートは ExceptionList と呼ばれ、ツリーはゼロ個以上の例外記述のセットから構成されます。例外リスト・ツリーは、例外が発生した場合に、メッセージ・フローによって移植されます。メッセージ・フローの処理中に例外条件が発生しない場合には、そのメッセージに関連した例外リストは、ルート・エレメントのみから構成されます。
このリストは、実際には、例外の空のリストです。
例外リスト・ツリーは、例外の発生後にメッセージを受信する、メッセージ・フロー内の他のノードがアクセスすることができます。アウトバウンド・メッセージ・ツリーを変更するためのインターフェースを設けているノード (Compute ノードなど) のみで例外リスト・ツリーの内容を変更できます。
例外条件が発生した場合、メッセージ処理は中断され、例外がスローされます。
制御は高位、つまりエンクロージング・キャッチ・ブロックに戻されます。障害条件を記述する 例外リストが作成され、メッセージ全体がローカル環境ツリーおよび新たに移植された例外リストと共に、例外処理メッセージ・フロー・パスを介して伝搬します。
ExceptionList の子は常に RecoverableException です。ある環境では複数生成されることがありますが、通常はこのルートの子は 1 つだけ作成されます。ExceptionList の子には、多数の子が含まれており、その最後のものは、例外のタイプに特定の詳細情報を提供します。以下のリストでは、参照する可能性のある例外のタイプの一部を取り上げています。
- FatalException
- RecoverableException
- ConfigurationException
- ParserException
- ConversionException
- DatabaseException
- UserException
- CastException
- MessageException
- SqlException
- SocketException
- SocketTimeoutException
- UnknownException
以下の図に、リカバリー可能な例外の例外リスト・ツリーの構造を示します。
例外記述構造は、例外リスト・ツリーを生成するために、反復やネストが可能です。このツリーでは、
- 深さ (つまり、ルートからの親-子のステップ数) は、同じ例外に関する情報が、しだいに詳細になることを表しています。
- ツリーの幅は、処理が中止される前に発生した、別個の例外条件の数を表しています。
この数は通常 1 つで、結果として、互いの子として接続された例外記述の数から成る例外リスト・ツリーが作成されます。
- ツリー内の番号の付いたポイントで、
- この子は、RecoverableException、ParserException、DatabaseException、UserException、ConversionException、または MessageException のうちのいずれかになります。
これらのエレメントのすべてには、表示された子があります。最後の子が存在する場合、それはその親と同じエレメントです。
- このエレメントは繰り返されることがあります。
- 存在する場合には、この子は、その親と同じ子を含んでいます。
ツリー内の子は、例外の詳細を与える多数の名前値エレメント、および Insert という名前のゼロ個以上の名前エレメントの形式を取ります。
名前値エレメントで識別される、NLS (各国語サポート) メッセージ番号は、WebSphere® Message Broker エラー・メッセージを識別します。
Insert 値を使用して、このメッセージ内の変数を置換し、例外の原因の詳細を提供します。
上の図に示された例外リスト内の名前値エレメントを、以下の表で説明します。
名前 |
タイプ |
説明 |
File1 |
ストリング |
C++ ソース・ファイル名 |
Line1 |
整数 |
C++ ソース・ファイル行番号 |
Function1 |
ストリング |
C++ ソース関数名 |
Type2 |
ストリング |
ソース・オブジェクト・タイプ |
Name2 |
ストリング |
ソース・オブジェクト名 |
Label2 |
ストリング |
ソース・オブジェクト・ラベル |
Text1 |
ストリング |
追加テキスト |
Catalog3 |
ストリング |
NLS メッセージ・カタログ名 4 |
Severity3 |
整数 |
1 = 通知
2 = 警告
3 = エラー
|
Number3 |
整数 |
NLS メッセージ番号 4 |
Insert3 |
タイプ |
整数 |
値のデータ・タイプ
0 = 不明
1 = ブール
2 = 整数
3 = 浮動小数
4 = 10 進数
5 = 文字
6 = 時刻
7 = GMT 時刻
8 = 日付
9 = タイム・スタンプ
10 = GMT タイム・スタンプ
11 = 間隔
12 = BLOB
13 = ビット配列
14 = ポインター
|
テキスト |
ストリング |
データ値 |
注 : - File、Line、Function、および Text エレメントは、例外処理の意思決定には使用しないでください。
これらのエレメントは、情報がログに確実に書き込まれ、IBM® サービス技術員が使用できるようにします。これらのエレメントは、内容と順序の両方が変動する可能性があります。
- Type、Name、および Label エレメントは、例外条件の発生時にメッセージを処理していたオブジェクトを定義します (通常はメッセージ・フロー・ノード)。
- Catalog、Severity、および Number エレメントは、NLS メッセージを定義します。
示された 2 つの名前値エレメントを含む Insert エレメントは、その NLS メッセージへの挿入を定義します。
- NLS メッセージ・カタログ名および NLS メッセージ番号は、変換可能なメッセージ・カタログおよびメッセージ番号を参照します。
メッセージ・フローの処理が完了すると、例外リスト・ツリーは廃棄されます。
次のサンプルは、XML_Reservation メッセージ・フロー内の例外リストを使用して、エラー情報を
Throw ノードに渡します。このノードは、ExceptionList の情報を含むエラー・メッセージを生成します。
サンプルは、Message Brokers Toolkit と統合されているインフォメーション・センターを使用する場合にのみ表示できます。