[解決済み] .NETの場合 必要な設定がない場合、どの例外をスローするか？

質問

以下は標準的なシナリオです。

if(string.IsNullOrEmpty(Configuration.AppSettings["foobar"]))
   throw new SomeStandardException("Application not configured correctly, bozo.");

問題は、完全に確信があるわけではないのですが どの 例外 SomeStandardException であるべきです。

3.5 Frameworkを熟読し、2つの可能性の高い候補を見つけました。 ConfigurationException と ConfigurationErrorsException .

System.Configuration.ConfigurationException（システム構成.コンフィギュレーション例外

設定システムエラーが発生したときにスローされる例外です。 設定システム・エラーが発生したときにスローされる 発生したときにスローされる例外です。

備考

この ConfigurationException 例外は がスローされます。 例外が投げられます。 例外がスローされます。 がスローされます。考えられる理由 この場合、設定ファイル内のXMLが不正であること が不正である、ファイル のパーミッションの問題、およびコンフィギュレーション プロパティに有効でない値が含まれている が有効でない場合などです。

注意してください。

は ConfigurationException オブジェクトは は後方互換性のために維持されています。 そのため ConfigurationErrorsException オブジェクトに置き換わります。 オブジェクトに置き換わります。

この例外は私が必要としているものにぴったりなのですが、廃止されたので、atthayにイクナイします。

このため、完全に不可解な ConfigurationErrorsException :

System.Configuration.ConfigurationErrorsException（システム構成.コンフィギュレーション.コンフィギュレーションエラーズ例外

現在の値は EnableSessionStateの値ではありません。

ご覧の通り、そのドキュメントは全く役に立ちません。(ローカルとオンラインのヘルプの両方でそのようになっています。) クラス自体の検査は、私が欲しいもののために徹底的に過剰であることを示します。

一言で言えば、私は、アプリケーション構成設定が欠けているか、無効な値を含んでいるときに投げられるべき標準的な例外を必要とします。フレームワークには、アプリケーションが使用するために、そのような例外が焼きこまれていると思うでしょう。(それは明らかにそうでしたが、それは時代遅れとマークされ、何かで置き換えられました。 大いに より大きなスコープで置き換えられました)。

もしあれば、皆さんはどのようなソリューションを使用していますか？

編集の補足

一部の人は、デフォルト値を提供して続けることができるかどうか尋ねました。特定のケースでは、はい、そのようなケースでは、例外はスローされません。しかし、特定の設定については、これは適用されません。たとえば、データベース サーバー名と資格情報、認証サーバー、およびインストールされたサード パーティ製アプリケーションのパスなどです。

私が主に取り組んでいるアプリケーションはバッチモードで実行されるコンソールアプリケーションであり、適切に設定されていない場合に main メソッドによって捕捉され適切に記録される例外をスローするようにしたい、ということも注目すべき点です。(これは私が受け継いだレガシーコードで、現在は単に を想定しています。 を想定しています)。

どのように解決するのですか？

例外を投げるのは、Framework にある既存の例外に限定されるわけではありません。 もし、既存の例外を使うことになったとしても、絶対にドキュメントに従わなければならないわけではありません。 ドキュメントには、どのように フレームワーク が与えられた例外をどのように使用するかを説明しますが、どのようにしたら あなた は既存の例外を使用/再利用することを選択する方法について、いかなる制限も意味しません。

あなたのアプリケーションです。文書化し、設定値がない場合にスローされる例外を明確に示す限り、好きな例外を使用することができます。 もし、非常に具体的に 欠落 値の非常に具体的な表示が必要な場合は、独自の ConfigurationSettingMissing 例外を記述することを検討することができます。

[Serializable]
public class ConfigurationMissingException : ConfigurationErrorsException
{}

編集: この場合、独自の例外を書くことは、例外がどこから来るのか、フレームワークなのか、それともあなたのアプリケーションなのかについて、決して混乱しないことを保証するという付加的な利点を伴います。 フレームワークは決してあなたのカスタム例外を投げません。

UPDATE: コメントに同意したので、私はサブクラスをExceptionからConfigurationErrorsExceptionに変更しました。 アプリケーション固有の例外が必要な場合を除き、Exception クラスを避け、可能な限り既存のフレームワーク例外からカスタム例外をサブクラス化することが一般的に良いアイデアだと思います。