PolarDB:ユーザー定義の例外

ユーザー定義の例外がサーバーによって発生することはありません。 代わりに、RAISEステートメントによって明示的に生成されます。 ユーザー定義の例外は、開発者定義の論理ルールが壊れたときに発生します。 論理ルールが破られる一般的な例は、資金が不足している口座に対して小切手が提示されたときに発生します。 資金が不足している口座に対して小切手を現金化しようとすると、ユーザー定義の例外が発生します。

関数、プロシージャ、パッケージ、または匿名ブロックで例外を定義できます。 同じブロックで同じ例外を2回宣言することはできませんが、2つの異なるブロックで同じ例外を宣言することはできます。

ユーザー定義の例外を実装する前に、関数、プロシージャ、パッケージ、または匿名ブロックの宣言セクションで例外を宣言する必要があります。 その後、raiseステートメントを使用して例外を発生させることができます。

DECLARE
    exception_name例外;

開始
    ...
    RAISE exception_name;
    ...
エンド; 

exception_nameは例外の名前です。

未処理の例外は、コールスタックを介して伝播します。 例外が未処理のままである場合、例外は最終的にクライアントアプリケーションに報告される。

ブロック内で宣言されたユーザー定義の例外は、そのブロックに対してローカルであり、ブロック内のネストされたブロックに対してグローバルであると見なされます。 外側のブロックに存在する例外を参照するには、外側のブロックにラベルを割り当ててから、例外の名前の前にブロック名を付ける必要があります。

block_name.exception_name

逆に、外側ブロックはネストブロックで宣言された例外を参照できません。

宣言の範囲は、パッケージ内で作成され、参照された場合はパッケージ名で修飾されない限り、宣言されたブロックに制限されます。 たとえば、inventory_controlという名前のパッケージに存在するout_of_stockという名前の例外を発生させるには、プログラムは次の名前のエラーを発生させる必要があります。

inventory_control.out_of_stock

パッケージでユーザー定義の例外を宣言する例を次に示します。 ユーザー定義の例外は、例外と同じパッケージに存在するため、check_balanceで発生する場合、パッケージ修飾子は必要ありません。

パッケージの作成または交換
  誇張された例外;
  PROCEDURE check_balance(p_balance NUMBER、p_amount NUMBER);
エンド;

パッケージボディの作成または交換
   PROCEDURE check_balance(p_balance NUMBER, p_amount NUMBER)
   IS
   BEGIN
       IF (p_amount > p_balance) THEN
         RAISE overdrawn;
       END IF;
    エンド; 

次のプロシージャ (購入) は、check_balanceプロシージャを呼び出します。 p_amountがp_balanceより大きい場合、check_balanceは例外を発生させ、purchaseはar.overdrawn例外をキャッチします。 購入はarパッケージ内で定義されていないため、購入はパッケージ修飾名 (ar.overdrawn) で例外を参照する必要があります。

CREATE PROCEDURE購入 (customerID INT、金額NUMERIC)
AS
  BEGIN
     ar.check_ balance(getcustomerbalance(customerid) 、金額);
       record_purchase(customerid、金額);
  EXCEPTION
     ar.overdrawn THEN
       raise_credit_limit(customerid, amount * 1.5);
  エンド; 

ar.check_balanceが例外を発生させると、実行は購入で定義された例外ハンドラーにジャンプします。

例外
     ar.overdrawn THEN
       raise_credit_limit(customerid, amount * 1.5); 

例外ハンドラは、顧客の信用限度を引き上げ、終了する。 例外ハンドラーが終了すると、ar.check_balanceに続くステートメントで実行が再開されます。