C# 戻り値の型を動的に変更することは可能ですか？

ずっと気になっていたんですが「業務エラー」とは何なのでしょうか。業務エラー以外には、どのようなエラーがあるのでしょうか。nanbu さんが考えているエラーの種類を列挙していただいて分類していただけると、私にも理解できるかもしれないです。

私は「入力欄の文字がすべて数値で構成されている」とか「文字列がメールアドレスの書式を満たしている」などの検査ロジックは、業務依存性が低く「業務エラー」とやらには該当しないと勝手に思い込んでいたんですが…。どうやら違うっぽい。

引用:
業務エラーであるとした場合、業務エラーを表現するために「例外」を使用しませんので

では、どのようなエラーを表現する場合に「例外」の使用が適切なのでしょうか。前に、「アプリケーションエラー」「システムエラー」という言葉が出てきていますが、私はこれらを、かなり致命的な障害(Java の Error 相当)でキャッチすべきではない(==フローへの復帰が困難な)ものと認識していました。この認識がそもそも間違っているのかな？

引用:
それとも、クラスライブラリとしてパラメータ引数が有効であることをチェックしたときのアプリケーションエラーでしょうか。

この文脈からすると、アプリケーションエラーはそれほど致命的な状態をあらわすものではないような気もしてきます。

引用:
クラスライブラリとしてのパラメータチェックであれば、呼び出しメソッド側（クラスライブラリを使用するビジネスメソッド）で、範囲外例外を業務エラーとして切り替えることで実現します。

なぜ、わざわざ水際で例外をキャッチして、戻り値方式などに切り替える必要があるのでしょうか。例外をキャッチできるということはプログラマが例外がスローされることを理解しているのだから、(チェック例外でなくても)正しく扱えそうな気がしますが…。そもそも常に水際で例外をキャッチして戻り値方式に切り替えるくらいなら、汎用ライブラリ自体が例外を投げずに戻り値方式を採用していたほうが良くないですか？ なぜ、標準ライブラリは例外を投げているのでしょうか？

引用:
私は、モデルの意味合いが強そうなGoodsクラスは業務フローから切り離したいと考えますので、後者を選択します。

モデルとは何ですか？ MVC のモデルですか？ MVC のモデルだとした場合・・・モデルは業務フローから切り離したいと考える理由はなんでしょうか？ 私は MVC に関係なく Goods と命名されたクラスは業務依存性が高そうなので、業務フロー(設計)と密接な位置に置いておくほうがいいかな、と思いました。

また、ここで後者(アプリケーションエラー？)を選択すると「例外の使用が正当化される」というのも良く分かりません。

noderaさんの書き込み (2005-05-08 19:27) より:
こんにちは。

南部さんが使う言葉がちょっとあいまい（言葉の定義において南部さんの認識と他者の認識が一致していない）なんで誤解を招いているのだと思いますよ。自分も業務フローや業務エラー、ビジネスメソッドという言葉がどの辺りを指しているのか、何度も読み返してなんとなく判ってきたところです。

自分も南部さんにひとつたずねたいのですが、「CLRのデザインルール」ってのは具体的のどのドキュメントのどの部分を指しているのでしょうか？それを読めば、南部さんの言わんとしていることがもうちょっと理解できるかな。
ちなみにburton999さんが最初に貼り付けたリンク先には、「.NET の世界ではエラー処理が "エラー コード" を使用するスタイルから、 例外を使用するスタイルに移行している」と書いてあります。

.NETの例外は、Javaの検査例外のように呼び出し元に対し業務フローの分岐を強制させる(中略)ことはできませんので、「例外」は業務フローから出るときに使用し、業務ルートの分岐には戻り値を使用する

Jittaさんの書き込み (2005-05-08 21:43) より:
　想定されている例外が「業務エラー」なら、たとえば数値を入力するところで、「ここには『数値を表すラベル』を付けているのだから、数値以外の入力はない」と思いこんでいれば、想定されない例外が発生します。そして、プログラミング初心者は、そういうコーディングをよくするでしょう。
　しかし、「どんなリードの仕方をしても、ユーザは何を入力するかわからない」という前提に立てば、想定された例外が発生します。
　とすると、設計者やコーディング者の経験や知識によって、変わるのでしょうか。

未記入さんの書き込み (2005-05-08 23:14) より:

話が最初のところに戻ってしまうんですが、例外のキャッチが強制されないという技術的な制約があると「例外の使用を控えるべき」となってしまうのはナゼでしょうか。
（略）
どうでしょう？ 私はリファレンス必須でも例外を積極的に使っていくメリットは大きいと思うのですが。

nanbuさんの書き込み（2005-05-09 07:48）より：

そうですね。
設計者やコーディング者の経験や知識によって変わると思います。

nanbuさんの書き込み (2005-05-08 22:14) より:

例外と業務エラーの分類は
・業務エラー
　業務設計で想定されている範囲で処理が分岐する正常終了でないケース。
　⇒戻り値として表現

・アプリケーション/システムエラー
　業務設計で想定しない異常のため正常終了できないケース
　⇒例外で表現

Jittaさんの書き込み (2005-05-09 22:50) より:

　そうではなく、経験に左右されずに同じような設計／コーディングができるように策定されたのがガイドラインであり、ルールではないでしょうか。だとすると、どこまでを「想定の範囲」とするか、明確にする必要があると思います。

noderaさんの書き込み (2005-05-10 10:38) より:
こんにちは。

引用:
nanbuさんの書き込み (2005-05-08 22:14) より: 例外と業務エラーの分類は ・業務エラー 　業務設計で想定されている範囲で処理が分岐する正常終了でないケース。 　⇒戻り値として表現 ・アプリケーション/システムエラー 　業務設計で想定しない異常のため正常終了できないケース 　⇒例外で表現

ここは自分の考えとは違うところです。
「例外」＝「エラー」と考えて無いでしょうか？例外をエラー（業務エラーでもシステムエラーでも）かどうか判断するのは、呼び出す側であって、呼び出される側（スローする側）では無いと思います。

呼び出された処理は与えられた条件により、ある暗黙の前提（型や引数の範囲等）にしたがって処理を行います。例外をスローするということは、呼び出し側に対し、前提に違反しているということを通知することであり、呼び出された処理にとってはエラーではなく、予定された処理の一部なのです。

なので、呼び出される側が「エラーを通知しよう」という意識にたって結果コード（あえてエラーコードといわない）や、例外を取り扱うのはおかしいかなと思います。