メッセージ・ハンドラーの使用
作成時および実行時の処理エラーとそれ以外のメッセージに対するデフォルトの動作は、メッセージを System.err に印刷すること、さらにリカバリー不能エラーで XProcessException を表示することです。 作成時にエラーが発生すると、プロセッサーは作成を続行し、XProcessException を生成する前にすべてのエラーのシグナルを示そうとしますが、実行可能ファイルは生成されません。 実行時には、最初にエラー状態になった時点で実行が停止します。
手順
- XMessageHandler インターフェースで定義されている以下の列挙子のいずれかになります。
- エラーが単なる通知のためのもので、結果に影響を与えないことを示します
これは、終了属性の結果が "no" の場合に XSLT メッセージの説明にも使用されます。
- 警告を示します
プロセッサーは、警告状態から復旧しますが、結果は予期されたものでない可能性があります。
- リカバリー可能エラーを示します。
プロセッサーは、その他のエラーのシグナルを示すためにこのエラーから復旧する場合がありますが、結果は作成されません。
- リカバリー不能エラーを示します
プロセッサーはこのエラーから復旧できません。 これは、終了属性の結果が "yes" の場合に XSLT メッセージの説明にも使用されます。
- メッセージが XPath の fn:trace 関数の呼び出しによって生成されたことを示します
- エラーが単なる通知のためのもので、結果に影響を与えないことを示します
- エラー・メッセージ
- XSourceLocation (選択可能な場合) としてのソース・ロケーション
一般に、ソース・ロケーションは実行時エラーの場合には選択できません。
- エラーを引き起こした元の例外 (使用可能な場合)
例えば、入力文書が無効である場合、XML パーサーはこのパラメーターを通じてレポート・メソッドに渡される例外を生成します。
- XPath の fn:error 関数で、エラー・オブジェクト・パラメーターに指定されている項目
XMessageHandler の実装では、メッセージを System.err に送信するのではなくログ・ファイルに書き込むなど、要求どおりにエラーと他のメッセージを表示できます。 より厳密に、例外を生成して、エラー (リカバリー可能エラーも含む) の後にコンパイルまたは実行を停止する場合もあります。 レポート・メソッドには throws 節がないため、例外を未チェックにする必要があります。 実装で通知メッセージと警告メッセージを無視するように選択する場合もあるでしょう。 要するに、XMessageHandler を登録することで、アプリケーションはメッセージ処理をその目的に応じて構成できるようになります。
リカバリー不能エラーの場合は、登録されたメッセージ・ハンドラーが例外を生成しなければ、プロセッサーによって XProcessException が表示されます。