C#と諸々業務エラーの表現方法

未分類

2006/10/08 04:29

業務エラーというのは、業務固有（アプリケーション固有）のエラーのこと。
例えば、DBに業務情報を格納しておくWebアプリで、あるユーザーが業務情報を登録しようとした時に、その業務情報に関連する情報が他のユーザーによって削除されていて、外部キー制約違反が起こってしまう場合などが該当する。

[ 業務エラーはApplicationExceptionで？ ]
オレは今まで、業務エラー時にはApplicationException派生の自作クラスをスローしてた。
だって、ApplicationExceptionの説明には

ApplicationExceptionは、共通言語ランタイムではなく、ユーザープログラムによってスローされます。デザインしているアプリケーションで固有の例外を作成する必要がある場合は、ApplicationException クラスの派生クラスを生成します。ApplicationException クラスは Exception を拡張しますが、新しい機能は追加しません。この例外は、アプリケーションで定義された例外とシステムで定義された例外を区別する手段として提供されます。

って書いてあるし、

Application Architecture for .NET （通称AAfN ）の第三章にも、

例外クラスは、ApplicationException の派生クラスとして作成します。

とか、

例外には大きく分けて、業務上の例外と技術上の例外の 2 種類があります。例外をこのように分類することにより、アプリケーションのさまざまなコンポーネントで該当する種類の例外をキャッチし、発行する処理を簡単に実現できるようになります。

技術上の例外 (データベース接続の失敗など)

業務上の例外 (外部キー制約の違反など)

って書いてあるから。（あとここにも。）

[ 業務エラーは戻り値で？ ]
でも、クラスライブラリ開発のデザインガイドラインの中のカスタム例外のデザインでは、

「標準の例外の種類のキャッチとスロー」のガイドラインに示されているように、ApplicationException からカスタム例外を派生させることは推奨されていない点に注意します。

なんて書いてある。（対象がクラスライブラリ開発だからか・・・？）

書籍「 Microsoft Visual Studio 2005 による Webアプリケーション構築技法」でも、「 6.4 例外処理」で、DBに対して顧客情報を新規登録するメソッドを例に挙げ、終了パターンを以下のように３つに大別した上で、

・正常終了
受け渡された顧客情報を利用して、正常にデータベースに顧客情報が登録された場合。

・業務エラー
希望された顧客IDがすでに他の顧客により利用されていたといった理由により、顧客情報が登録できなかった場合。

・アプリケーション／システムエラー
データベース障害やネットワーク障害により、データベースの読み書きが行えなかった場合。

それぞれの表現方法を以下のように示している。（実際は表形式）

分類：
正常終了
対応するケース：
業務で期待された主たる処理が問題なく終了した場合
.NETでの表現方法：
戻り値の一部として表現

分類：
業務エラー
対応するケース：
業務設計の中で想定されている範囲内で、処理が分岐し、正常終了できなかった場合
.NETでの表現方法：
戻り値の一部として表現

分類：
アプリケーション／システムエラー
対応するケース：
業務設計の想定範囲外の異常事態が発生し、アプリケーション処理を正しく遂行できなくなった場合
.NETでの表現方法：
例外を用いて表現

[ ふむ・・・ ]
ということで、業務エラーについては、以下の２つの意見があるようだ。

・ApplicationExceptionの派生クラスを定義し、それをスローする。
・例外は用いず、戻り値（ BooleanとかEnumってことかな）で表す。

どっちがいいんだろ？
いや、単に人それぞれの好みで選んでいいのかな？
考察してみると面白そうだし、もしかしたらそのうち考察記事書くかも。

[ 追記 ]
例外処理の実装だと、ApplicationExceptionではなくExceptionを派生させろって書いてあるな・・・。

ほとんどのアプリケーションでは、Exception クラスからカスタム例外を派生します。本来、カスタム例外は ApplicationException クラスから派生しなければならないと考えられていましたが、実際には、このことで大きな価値が付加されたことはないようです。

タグ: .NET C# 例外処理

トラックバック(0) | コメント(8) |

微妙ですよね・・・
「プログラミングMicrosoft .NET Framework」にもありますが、
Javaとも少し違いますし、難しいですよね。
毎回悩みます。
古いですが、以下のような内容からもやはり、定義は難しいですね。
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?mode=viewtopic&topic=21003&forum=7&start=16

ぜひ考察記事待ってます。

2006.11.22 14:44　URL | Yuji #-　[ 編集 ]

Yujiさん、初めまして。コメントありがとうございます＾＾
リンク先、拝見しました。例外に関する話題ってやっぱり難しいですね。。。
私の考察なんてたいしたものにはならないと思いますが、近々考察記事を書いてみようと思います。

2006.11.23 17:34　URL | よこけん #-　[ 編集 ]

処理続行可能かどうか
nullを渡されてはいけないようなものは例外
100円以下を入れてほしい場合には業務エラー(非例外)
とします。(原則)

2006.12.04 14:10　URL | 中博俊 #-　[ 編集 ]

中博俊さん、初めまして。コメントありがとうございます。

＞ nullを渡されてはいけないようなものは例外
＞ 100円以下を入れてほしい場合には業務エラー(非例外)
＞とします。(原則)

それはもはや定説なのでしょうか？私がコミュニティーなどでよく見かけるのも、そっちの意見です。
個人的には、どちらが正しくてどちらが間違いといったものではないのだと思っていたのですが…。

2006.12.05 00:14　URL | よこけん #-　[ 編集 ]

考察記事を書いてみました。
http://csharper.blog57.fc2.com/blog-entry-53.html

2006.12.06 16:13　URL | よこけん #-　[ 編集 ]

すみません、意見が180度変わりました。
詳細はこちらの記事を参照してください。
http://csharper.blog57.fc2.com/blog-entry-99.html

2007.02.25 04:47　URL | よこけん #-　[ 編集 ]

要件を満たせれば (要件を実現できて、品質的に問題なければ) なんでもいいと思います。
逆に、理論やポリシーがあっても要件を満たせなければ意味がないと思います。

ポリシーもなく、要件も満たせないシステムが多いですが。。。

2010.05.05 13:21　URL | toki #5rjYxIKk　[ 編集 ]

承認待ちコメント
このコメントは管理者の承認待ちです

2012.01.05 23:09　 | #　[ 編集 ]