C#と諸々

---

2007/02/25 追記

この記事に書いたことは、現在の私の意見とは異なります。
現在は、業務エラーは例外で表すべきと私は考えています。
詳細はこちらの記事を参照してください。

---

以前書いた業務エラーの表現方法ついての考察。
経験不足が否めない。。。
つっこみしてくれる方大募集！ｗ

【 業務エラーの定義 】
まず、Application Architecture for .NET の第三章 ( 以下、AAfN ) と、書籍 「 Microsoft Visual Studio 2005 による Webアプリケーション構築技法 」 ( 以下、赤間本 ) での、業務エラーの定義に差異はないか？

[ AAfN ]
AAｆNでは、例外を以下のように分類している。


[ 赤間本 ]
赤間本では、例外を以下のように分類している。


また、赤間本では、業務エラーとアプリケーション／システムエラーの切り分け方として、「業務設計の中で想定されていなければならないケースが業務エラー」というようなことも書かれている。

[ 比較 ]
AAfNは外部キー制約の違反、赤間本は一意キー制約の違反を例に挙げている。これらは、「他のユーザーが既に登録／編集済み」などが原因で発生する。
どちらもあまり詳細には書かれていないが、定義の差異はなさそうだ。
個人的には、「エンドユーザーに許容されている範囲内での、エンドユーザーの操作 ( 入力 ) 次第で発生しうる、正常系でないフローが業務エラー」で、「システム異常など、まさに例外的な状況がアプリケーション／システムエラー」だと解釈している。


【 戻り値と例外 】
業務エラー云々を抜きにして、戻り値と例外について分析してみる。

[ 戻り値 ]
与えられた入力 ( 引数 ) に操作を適用した結果生じる出力。
引数と違い、返せるオブジェクトは一つだけ。
固定の型。
戻り値は呼び出し元でしか受け取れない。

[ 例外 ]
操作の途中で、例外的な状況に陥った場合に、通常とは異なるフローで、その例外情報を上位に伝播する。
例外メッセージ、スタックトレース、例外の元となった例外など伝播される情報が多い。
例外そのものは、例外の分類に応じた型 ( Exception派生クラス ) となる。
例外は例外ハンドラで処理する。その際、捕らえる例外を限定することができる。
スローされた例外は、対応する例外ハンドラが現れるまで上位に伝播される。
特殊な情報伝播を行うため、コストが高い。


【 業務エラーの表現方法の分析 】

[ 業務エラーの内容 ]
どのような業務エラーが発生したのかを知る必要はあるか？
これは、「ある」と思う。
DBの制約に関する業務エラーを例に挙げると、「IDが重複 ( 一意キー制約に違反 ) しているのか？」、「削除されたアイテムを参照 ( 外部キー制約に違反 ) しているのか？」、「違反している場所はどこなのか？」といった情報は、どこを修正すればいいのかが明確になり、有益である。

・業務エラーを例外で表した場合
ExceptionのMessageプロパティに、どのような業務エラーが発生したのか記述することができる。

・業務エラーを戻り値で表した場合
戻り値の型がBoolean型だと、どのような業務エラーが発生したのかは不明となる。ただし、業務エラーが一つの理由でしか発生しない場合は、Boolean型でも明確となる。また、チェック系メソッドを用意して事前にチェックを行えるようにしておけば、業務エラーの内容を知ることができる。
また、戻り値の型を、Boolean型ではなくEnum型にすれば、業務エラーに応じた戻り値を返せる。

[ スタックトレース ]
業務エラーを例外で表した場合は、スタックトレースが利用できるが、スタックトレースは必要か？
これは、「不要」である。そもそも業務エラーは「設計時に想定されている状況」なのだから、スタックトレースなんて見る必要がない。

[ 上位での処理方法 ]
先に述べたように、戻り値は呼び出し元でしか受け取れない。例外は、対応する例外ハンドラが現れるまで上位に伝播される。
最上位に例外ハンドラを用意するだけで済むので、例外の方に分があるように思える。

【 考察 】
一見すると、戻り値の方が処理がめんどうで、例外に分があるように見える。
しかし、業務エラーの内容を伝えるのにExceptionのMessageプロパティを使うのは、あまり適 切ではないように思う。GUIに表示するメッセージを下位層で決めているようなものだ。業務エラーは文字通り「業務」上のエラーなので、表示・表示内容の 責任を持つのはGUIである。しかも、文字列なので、上位層の「プログラムコード」で業務エラーの詳細を判別できない。 ( 各業務エラーごとにExceptionクラスを定義したり、独自のプロパティなんかを用意してやればなんとかなりそうだけど。 )
そもそも、業務エラーは設計時に想定されている事象なので、例外的な状況ではない。 ( という話をどこかで聞いた。 )


【 結論 】
「業務エラーは戻り値で表現」です。