導入
メインフレーム開発において、業務ロジックの複雑化に伴い、エラーハンドリングの重要性は増しています。特に、ネストの深いルーチンや複数のプロシージャを跨いだ異常終了処理を行う際、単純な戻り値チェックだけではコードが煩雑になりがちです。PL/Iの「CONDITION」機能を使うことで、業務エラーを構造化し、メインルーチンや共通エラー処理ルーチンへ効率的に制御を移すことが可能になります。本稿では、保守性の高い例外処理の実装方法を解説します。
基礎知識
PL/Iにおける「CONDITION」とは、プログラマが独自に定義できる例外状態のことです。システム定義の例外（SUBSCRIPTRANGEなど）とは異なり、特定の業務ロジック上で「この条件が発生したら即座に処理を中断・分岐させる」という意図を明確にできます。`DECLARE`で条件名を宣言し、`ON CONDITION`文で発生時のハンドラを登録、`SIGNAL CONDITION`文で実際に例外を発生させるという3ステップで構成されます。
実装/解決策
実装のポイントは「ハンドラの有効範囲」と「制御の復帰」です。ONユニットは宣言されたブロック内、あるいは呼び出しスタックを通じて有効になります。例外発生後に処理を完結させるのか、あるいはエラーログを出力してプログラムを終了させるのか、設計段階でハンドラの責任範囲を明確にしてください。
サンプルプログラム
以下のコードは、業務上の異常事態が発生した際に、特定のクリーンアップ処理へジャンプする例です。
/ ユーザー定義の条件を宣言 /
DCL DATA_INCONSISTENCY CONDITION;
/ メイン処理 /
MAIN_PROC: PROC OPTIONS(MAIN);
/ 例外発生時のハンドラ設定 /
ON CONDITION(DATA_INCONSISTENCY) BEGIN;
PUT SKIP LIST(‘業務エラー発生：データ不整合を検知しました。’);
GOTO CLEANUP_ROUTINE;
END;
/ 業務ロジックのシミュレーション /
CALL VALIDATE_DATA(0); / 例として異常値を渡す /
RETURN;
CLEANUP_ROUTINE:
PUT SKIP LIST(‘リソースの解放と異常終了処理を実行します。’);
END MAIN_PROC;
/ データ検証用サブプロシージャ /
VALIDATE_DATA: PROC(VAL);
DCL VAL FIXED BIN(31);
IF VAL = 0 THEN
/ 異常時に条件をシグナル（発生）させる /
SIGNAL CONDITION(DATA_INCONSISTENCY);
END VALIDATE_DATA;
応用・注意点
現場での運用上の注意点として、`ON CONDITION`を広範囲に設定しすぎると、どこで例外が発生したのか追跡が困難になる場合があります。可能であれば、例外発生箇所ごとにハンドラを局所化するか、ハンドラ内でエラーコードを共通変数にセットする運用を推奨します。また、現代的な言語への移行を想定する場合、この`CONDITION`名をそのままクラス名や例外IDとして設計ドキュメントに残しておくと、将来的なリファクタリング時に非常に役立ちます。安易な`GOTO`の乱用は避け、あくまで「異常終了」や「大域脱出」の目的で使用することに留意してください。
コメント