条件ハンドラーのアクション句は、入れ子または入れ子ではない複合文にできます。アクション句で発生した例外条件、完了条件、またはユーザー定義条件は、アクション句の中に定義されているハンドラーで処理できます。
ハンドラー アクションで発生する条件がアクション句の中で処理されない場合、その条件は適切なハンドラーの検索のために外側に伝搬されることはありません。複合文に関連した他のハンドラは、ハンドラーで発生した条件を処理することはできません。このような条件は処理されずに残ります。唯一の例外は、RESIGNAL文です。その条件は、ハンドラ内の複合文のアクション句の外に伝搬されます。
以下の表では、処理されない例外条件、完了条件、ユーザー定義条件を比較しています。
処理されない条件の種類 | 結果 |
---|---|
例外条件またはユーザー定義条件 | ハンドラーが終了し、そのハンドラーを呼び出した元々の条件が、適切なハンドラーを探すために外側に伝搬されます。 元の条件に対する適当なハンドラーが存在しない場合、ストアド プロシージャは終了します。 |
完了 | 条件は無視され、ハンドラー アクション内の次の文から実行が続けられます。 |
以下の事例でこれらの状況について説明します。
事例1
以下は、処理される新しい例外を引き起こす例外条件のハンドラー アクション例です。
- ストアド プロシージャで例外が発生し、参照されたデータベース オブジェクトが存在しないことを意味するSQLSTATEコード’42000’が発生します。
- 例外条件が条件ハンドラーによって処理されます。
- その後、ハンドラー アクションで、ゼロ除算の例外’22012’が発生します。
- 文のハンドラー アクション グループの中にこの例外を処理するためのハンドラーが存在するので、これは処理されます。
事例2
以下は、処理されない新しい例外を引き起こす例外条件のハンドラーアクション例です。
- ストアド プロシージャで例外が発生し、参照されたデータベース オブジェクトが存在しないことを意味するSQLSTATEコード’42000’が発生します。
- その後、ハンドラー アクション句で、ゼロ除算の例外’22012’が発生します。
- 文のハンドラーアクション グループの中に、この新しく発生した例外に対する適当なハンドラーが存在しない場合、ハンドラーを探すために新しく発生したこの条件が外側に伝搬されることはありません。
- このハンドラー アクションは終了し、元の例外条件である’42000’は、適切な条件ハンドラーを探すために外側に伝搬されます。
- 元の条件に対して適切なハンドラーが見付からない場合、ストアド プロシージャは終了し、元の例外条件である’42000’に対応するTeradata Databaseエラー コードが戻されます。
事例3
以下は、例外を引き起こす完了条件のハンドラーアクション例です。
- 要求したサンプル サイズはテーブルの行よりも大きいことを意味するSQLSTATEコード’T7473’で、ストアド プロシージャは完了条件(警告)を発生します。
- その後、ハンドラー アクションで、テーブルへの重複行の挿入の試行に関する例外条件’23505’が発生します。
- ’23505’に対する適切なハンドラーがハンドラー アクションの中に存在すれば、この条件は処理されます。
- ’23505’に対する適切なハンドラーがハンドラー アクションの中に存在しない場合、元の条件である’T7473’は、この条件を処理するための適切なハンドラーを探すために外側に伝搬されます。
- 元の完了条件が処理された場合で、
- ハンドラーがCONTINUEタイプである場合は、完了条件が発生した文からストアド プロシージャの実行が続けられます。
- ハンドラーがEXITタイプである場合、制御はEXITハンドラーを含む複合文を終了します。
完了条件が処理されない場合は、次の文からストアド プロシージャの実行が続けられます。
事例4
以下は、別の完了条件を引き起こす完了条件のハンドラー アクション例です。
- ストアド プロシージャで、要求したサンプル サイズはテーブルの行よりも大きいことを意味する完了条件’T7473’が発生します。
- 完了条件が汎用条件ハンドラーによって処理されます。
- その後、ハンドラーアクションで「no data found」完了条件が発生します。
- この新しい完了条件は無視され、残りの文でストアド プロシージャの実行が続けられます。