ウィジェットコメントの編集Name:Mail:Home:Comment:Katoです。ご返答ありがとうございます。私が第一に考えていることは、『予め想定(定義)された業務エラーには例外を使用しないということ』は、.NET上の制約ではないかということです。ゆえに、(現在は).NETの機能を最大限活かすためにそれに沿って考えようとしています。例外の持っている機能(良さ)を否定しようと思っているわけではありません。『例外(Exception)脳の作り方』にかぶれてそれを無理やり.NETに持ち込もうと格闘していた時期があったくらいですので(笑)。.NETの"例外"はシステム上(論理上)では想定されるエラーも含まれますが、予め想定されないエラーを処理するためにあるものと理解しています。"業務エラー"というものは予め想定されていますので、フロー上にも記述でき、広義でいえば正常系に含まれるものと言えます(考えます)。その通りだと思います。そのような可能性のある箇所に対しては、正常系(処理)、業務エラー(処理)を包含する形で例外(処理)を施すと考えます。業務エラーは、予め想定されていますのでもともと多くの情報を必要としないはずです。今回の事例については、私としては"業務エラー"ではなく元々"例外"として扱われるべきものではないかと思います。正しくは、"例外"と断定せず、楽観同時実行により起こる状況を"業務エラー"として扱うかというビジネス上の判断により、SQLExceptionでキャッチして、"業務エラー"として処理すべきか、そのまま"例外"として処理すべきか決まるものだと思います。上記のような場合で使用されるものと考えます。私はSqlExceptionクラス設計者が何を意図してそのように実装したのかを考え(想像し)、それを最大限有効に活用しようと考えています。仮に、それが私個人の意に反し、またスマートではないと思えても、です。#クラス設計思想を暴露するような本があれば、面白いと思うのですけれど。そのように.NETのクラスを観察すると理路整然としない、人間くささを感じることが時々ありますが、それはそれで便利だと理解することがほとんどです。例としてはあまりよくなかったと思います。最近Webサービスを結合にに使用することが多かったものですから。#ご指摘を受けて思い出しました。「型」の代わりに「エラーコード」を使うというのはどうでしょうか、ともめました(苦)。フォローとは、try{}でくくるという意味です。私は.NETではこのよう扱えと考えています(ほぼ引用)。業務設計で想定されている範囲で処理が分岐する正常終了でないケース。業務設計で想定しない異常のため正常終了できないケース。設計時に「業務エラー」と「アプリケーション/システムエラー」の分類を的確に行い、その上で実装しなければならない。状況によっては、「業務エラー」を「アプリケーション/システムエラー」に切り替えたり、「アプリケーション/システムエラー」を「業務エラー」に切り替えるコードが必要になる場合がある。キャッチした例外から戻り値を返すことも(その逆も)ありだと考えています。29ブログ内検索カウンターアクセスカウンターおすすめプロフィールAuthor:よこけん性別は男です。生年月日は1984年2月頃です。社会人は2004年4月頃からやってます。C#は2004年10月頃からやってます。このブログは2006年7月頃からやってます。アプリケーションリンクopus-i商用可・加工可で、綺麗な素材を提供していらっしゃいます。紹介していらっしゃいます。中心に扱っていらっしゃいます。コマンドレットをまとめたスナップインです。クラスライブラリを作ってみました。最近の記事ブログ移転しました。返事を返せない場合があります。