一般にエラーケースあるいは“例外系”などと称される処理の終了ケースを整理し、類型化してみました。なお、ここでいう「処理」とはおおよそ「業務ロジック」のことです。
■ エラーケースの基礎的な分類
まず、処理（業務ロジック）が、機能要件として期待されている内容を完遂できたか否かで、下記の二つに分けます。
"completed"ケース ... 処理が完遂できた場合
・（参照系処理においては、）その処理が呼び出し側に返却するはずのデータセットを確かに返却するに至った場合・（更新系処理においては、）その処理の実行の結果為されるはずの永続化データの更新が確かに実施され、トランザクションのcommitに至った場合
"incomplete"ケース ... 処理が完遂できなかった場合
・（参照系処理においては、）様々な理由により処理の実行が中断され、データセットを返却するに至らなかった場合・（更新系処理においては、）様々な理由により処理の実行が中断され、データ更新を実施するに至らず、トランザクションはroll backした場合
※"incomplete"ケースの原因たる「様々な理由」には、例えば「処理呼び出し時の事前条件を満たさなかった」、「処理実行中にDB接続エラーなどの物理障害が発生した」、「論理バグにより処理が実行停止に陥った」といったものを想定しています。
次に、"incomplete"ケースを、"Design by Contract"の観点に基づきつつさらに二つに分けます。
"recoverable"ケース
処理呼び出し側が、呼び出し時の手続き的なお約束＝“契約”を守らなかったことにエラーの原因を求める場合です。呼び出された側の内部状態は“正常”状態を維持できています。
処理がこのケースで終了した時、処理を呼び出した側において、原因に対する対策として適切なエラー回復措置を取ることが期待されます。個々のエラー回復措置は、処理呼び出し側におけるユースケースで（代替フローとして）各々明示されることが期待されます。原因が処理を呼び出した側にある故、処理を呼び出した側でエラー回復措置が取れる、という意味で"recoverable"ケースと称することとします。
"unrecoverable"ケース
呼び出された側の内部的な不具合や障害を要因として、処理の実行が中断されたり、処理実行後に不変条件や事後条件から逸脱していることを検知して処理の実行を取消した場合です。呼び出された側の“契約不履行”にエラーの原因があると認識します。呼び出された側は“異常”状態に陥ったと捉えられます。
処理がこのケースで終了した時、処理を呼び出した側では、アプリケーションを実行停止する以外に可能なエラー回復措置はありません。処理を呼び出した側でエラー回復措置が取れないという意味で"unrecoverable"ケースと称することとします。
■ 「成功終了」、「失敗終了」、「異常終了」を定義する
前節にて、
- "completed"ケース- "incomplete"で"recoverable"なケース- "incomplete"で"unrecoverable"なケース
という三つのケースを抽出しました。これらをそれぞれ「肯定的正常終了」、「否定的正常終了」、「異常終了」と命名、定義します。また、「肯定的正常終了」と「否定的正常終了」には、それぞれ「成功終了」、「失敗終了」という別名を与えることとします。（※以降、基本的に「成功終了」、「失敗終了」の方を用います。）
completed - 肯定的正常終了 成功終了 normal end (positive) regular incomplete recoverable 否定的正常終了 失敗終了 normal end (negative) irregular incomplete unrecoverable 異常終了 - abend -
「成功終了」はいわゆる"normal end"に対応付ける事ができます。
「失敗終了」は呼び出された側の内部状態は“正常”が維持されているという点から、「成功終了」同様の"normal end"の一つのケースと捉えます。ただし「成功終了」は“肯定的な”結果が得られたのに対し、「失敗終了」は“否定的な”結果が得られた、ものと捉えます。より日常的に、「成功終了」は"regular"ケース、「失敗終了」は"irregular"ケースである、と表現することにします。
「異常終了」はいわゆる"abend"に対応付ける事ができます。
「異常終了」のケースは、品質保証・品質管理における「故障（failure）」に相当するものとして捉えています。「失敗終了」は品質保証・品質管理における「故障」とは捉えません。"incomplete"、即ち処理が完遂されなかったケースは、広くエラーケースではあるものの、故障ではなくシステムとして“正常”状態を保っている（＝consistencyやintegrityが維持されている）「失敗終了」のケースと、故障でありシステムとしてconsistencyやintegrityに破綻があるといえる「異常終了」のケースとに分別できる、という認識をします。
※上の段落では、用語「故障」以外、特に「エラー」は日常用語として用いています。用語「故障」のみ品質保証・品質管理用語としての使用です。
◇
＜追記＞
「失敗」も英語で"failure"であり、品質保証・管理の「故障（failure）」と区別が付かないので、本記事で別名として用意した「成功終了」、「失敗終了」という用語ではなく、やはり「肯定的正常終了」、「否定的正常終了」の方を用いるべきかもしれません。
一方、背景理解のために用語「故障」を登場させましたが、日常の開発ではそれを意識すること無く「異常終了」、「失敗終了」、「成功終了」の用語を用いていて支障は無いとも思われます。
◆以上
（※次回へ続きます。）
