プリミティブ・オペレーターのランタイム・エラー

リカバリー不能エラー

リカバリー不能エラーの場合、 C++ または Java™ 内から例外をスローする選択肢しかありません。 C++ では、オペレーター開発者は、 std::exception のサブタイプである例外をスローすることができます。 その what() メンバー関数では、エラーの意味のある原因が示されます。 Java では、 開発者は、意味のあるメッセージを含む java.lang.Exception ファミリーの例外をスローすることができます。 キャッチされていない例外は、オペレーターと、そのオペレーターを含む処理要素を終了させます。 最終的に、正常でない状態はIBM® Streams インスタンスに報告され、streamtool、Streams Studio、またはログ・メッセージを使用してこれを検査できます。

例外のスローに加えて、開発者はトレース項目を作成する必要があります。 C++ のプリミティブ・オペレーターは、SPLAPPTRC マクロを使用でき、 Java のプリミティブ・オペレーターは java.util.logging.Logger インターフェースを使用できます。 問題を記述していて、かつ、grep などの標準ユーティリティーで検索しやすいように構造化されたトレース・メッセージを作成してください。 同じ側面を持つ関連エラーは、トレース・ファイル内で検索しやすいようにタグ付けします。

FileSource オペレーターにおけるリカバリー不能エラーの例として、 指定されたファイルが読み取り用に開けない場合や、結果のファイルを移動する場所を指定したオプション・パラメーターが無効なディレクトリーである場合があります。 これらのエラーはどちらも、オペレーターの目的に対して重要です。 これらのエラーが発生した場合は、オペレーターがそれ以上実行することはありません。 そのような場合、選択肢としては、終了することしかありません。

リカバリー可能エラー

エラー発生の報告には、いくつかの一般的な方法があります (エラーのロギングなど)。 ログは、エラーにつながったイベントを再現するために便利です。 ただし、ログ自体は、アプリケーションの動作に関する集約情報は提供しません。 メトリックとしてリカバリー可能エラーを記録すると、そうした概要を提供することができます。 オペレーター開発者は、カスタム・メトリック API でエラー・メトリックを定義できます。

アプリケーション内の他のオペレーターが実行時にエラーについて認識する必要がある場合、 オペレーター開発者は、不良タプルのみを受け取るオプションの出力ポートを定義することができます。 これらのエラー出力ポートはオプションで、正しくないタプルの処理をユーザーが強制されることはありません。 このようなポートには、エラーに関連したデータだけが含まれています。 エラー・データの形式は、発生したエラーのタイプを示す状況メッセージであることも、単にエラーを起動したタプルであることもあります。

解析モードに応じて、FileSource オペレーターがリカバリー可能エラーを処理する方法は異なります。 まず、FileSource オペレーターが解析中のエラーを致命的とみなすか、リカバリー可能とみなすかを構成することができます。 解析が strict に設定されている場合、解析中のエラーはすべて、リカバリー不能エラーとみなされます。 解析中のエラーからリカバリーすることは可能ですが、 この方法では、オペレーター・パラメーターを使用したランタイム・エラー処理の調整を示しています。 有効なエラー処理方法が複数ある場合、ベスト・プラクティスとしては、 オペレーターのユーザーがオペレーター・パラメーターを通して必要な動作を指定できるようにします。 デフォルト動作は、最も慎重な選択肢でなければなりません。

FileSource オペレーターが permissive モードの場合、 現行の潜在的なタプルを無視して次に移ることで、入力内のエラーからのリカバリーを試行します。 そうしたオカレンスはログに記録され、それに応じてメトリックが更新されます。

FileSource オペレーターの最後の解析動作は fast です。これは、すべての入力タプルの形式が正しいことを想定しています。 このモードでは、エラー検査が実行されません。 そのため、解析は可能な限り速くなりますが、結果として、入力のエラーにより不確定な動作になります。fast モードは、エラー処理がないことを実際には表すものです。 入力の形式に関しては保証されていて、速度が主な課題である場合、エラー処理なしの戦略は妥当であると言えます。 ただし、FileSource オペレーターは、このモードは危険であることを明確に示していて、これはデフォルトにはなっていません。 デフォルトでは、オペレーターはエラーをリカバリーしようとします。エラーを認識しない最適化モードの提供は有効な方式ですが、 FileSource オペレーターのように、危険であることを明確に示す必要があります。 そうしたモードは、オペレーターのパラメーターを使用して明示的に要求する必要があります。