.NET : Quelle exception lancer lorsqu'un paramètre de configuration requis est manquant ?

Question

Voici un scénario standard :

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

Le problème est que je ne suis pas tout à fait certain dont exception SomeStandardException devrait être.

J'ai parcouru le cadre 3.5 et j'ai trouvé deux candidats possibles : ConfigurationException et ConfigurationErrorsException .

System.Configuration.ConfigurationException

L'exception qui est levée lorsqu'une erreur du système de configuration de configuration.

Remarques

Le site ConfigurationException exception est est levée si l'application tente de de lire ou d'écrire des données dans le fichier de configuration mais n'y parvient pas mais n'y parvient pas. Certaines raisons possibles peuvent inclure un fichier XML malformé dans dans le fichier de configuration, des fichiers, des problèmes d'autorisation, et des de configuration dont les valeurs ne sont pas valides.

Note :

Le site ConfigurationException est maintenu pour une compatibilité rétroactive. Le site ConfigurationErrorsException le remplace pour le système de configuration.

Cette exception semble en fait parfaite pour ce dont j'ai besoin, mais elle a été marquée comme obsolète, donc, ixnay on atthay.

Cela nous amène à la question très déroutante ConfigurationErrorsException :

System.Configuration.ConfigurationErrorsException

La valeur actuelle n'est pas l'une des valeurs de valeurs de EnableSessionState.

Comme vous pouvez le constater, sa documentation est totalement inutile. (C'est le cas dans l'aide locale et l'aide en ligne.) Un examen de la classe elle-même montre qu'elle est complètement inutile pour ce que je veux.

En bref, j'ai besoin d'une exception standard qui doit être levée lorsqu'un paramètre de configuration de l'application est manquant ou contient une valeur invalide. On pourrait penser que le Framework dispose d'une telle exception pour que les applications puissent l'utiliser. (Apparemment, c'est le cas, mais elle a été marquée comme obsolète et remplacée par quelque chose de semblable). beaucoup plus vaste).

Quelles solutions utilisez-vous, le cas échéant, et vais-je devoir me résigner et créer ma propre exception ?

Modifier les addenda

Certains ont demandé si je pouvais ou non fournir une valeur par défaut, et continuer. Dans certains cas, oui, et dans ces cas, l'exception ne serait pas levée. Cependant, pour certains paramètres, cela ne s'applique pas. Par exemple, les noms et les informations d'identification des serveurs de base de données, les serveurs d'authentification et les chemins d'accès aux applications tierces installées.

Il est également utile de noter que l'application sur laquelle je travaille principalement est une application console fonctionnant en mode batch, et je veux qu'elle lève une exception qui est attrapée par la méthode principale et enregistrée de manière appropriée si la chose n'est pas configurée de manière appropriée. (C'est un code hérité que j'ai hérité, et actuellement juste suppose que tout est chouette).

Answer 1

Personnellement, j'utiliserais InvalidOperationException car il s'agit d'un problème lié à l'état de l'objet, et non au système de configuration. Après tout, ne devriez-vous pas permettre que ces paramètres soient définis par le code et non par la configuration ? L'important ici n'est pas qu'il n'y ait pas de ligne dans app.config, mais qu'un élément d'information requis ne soit pas présent.

Pour moi, ConfigurationException (et son remplaçant, ConfigurationErrorsException - malgré les documents MSDN trompeurs) sont destinés aux erreurs de sauvegarde, de lecture, etc. de la configuration.

Answer 2

Vous n'êtes pas limité dans vos lancements d'exceptions aux exceptions existantes dans le Framework. Si vous décidez d'utiliser des exceptions existantes, vous n'êtes pas obligé de suivre la documentation à la lettre. La documentation décrira comment le cadre utilise une exception donnée, mais n'implique aucune limitation sur la manière dont les vous choisir d'utiliser/réutiliser une exception existante.

C'est votre application - tant que vous la documentez et que vous indiquez clairement l'exception qui sera levée dans le cas spécifique d'une valeur de configuration manquante, vous pouvez utiliser l'exception que vous voulez. Si vous voulez une indication très spécifique d'une exception de type manquant vous pouvez envisager d'écrire votre propre exception ConfigurationSettingMissing :

[Serializable]
public class ConfigurationMissingException : ConfigurationErrorsException
{}

EDIT : Dans ce cas, écrire votre propre exception présente l'avantage supplémentaire de garantir qu'il n'y aura jamais de confusion quant à l'origine de l'exception : le framework ou votre application. Le framework ne lancera jamais vos exceptions personnalisées.

MISE À JOUR : je suis d'accord avec les commentaires, j'ai donc changé la sous-classe de la classe Exception en ConfigurationErrorsException. Je pense que c'est généralement une bonne idée de sous-classer les exceptions personnalisées à partir des exceptions Framework existantes lorsque cela est possible, en évitant la classe Exception à moins que vous n'ayez besoin d'une exception spécifique à une application.

Answer 3

Comme l'a dit Daniel Richardson, ConfigurationErrorsException est celui qu'il faut utiliser. En général, il n'est recommandé de créer vos propres types d'exception personnalisés que si vous avez un scénario pour les gérer. Dans le cas des erreurs de configuration, qui sont généralement fatales, c'est rarement le cas et il est donc généralement plus approprié de réutiliser le type existant ConfigurationErrorsException.

Avant la version 2.0 de .NET, il était recommandé d'utiliser l'option System.Configuration.ConfigurationException . ConfigurationException est devenu obsolète dans .NET 2.0, pour des raisons qui n'ont jamais été claires pour moi, et la recommandation a changé pour utiliser ConfigurationErrorsException.

J'utilise une méthode d'aide pour lancer l'exception afin qu'il soit facile de modifier l'exception lancée en un seul endroit lors de la migration de .NET 1.x à 2.0, ou si Microsoft décide de modifier à nouveau la recommandation :

if(string.IsNullOrEmpty(Configuration.AppSettings("foobar")))
{
   throw CreateMissingSettingException("foobar");
}

...

private static Exception CreateMissingSettingException(string name)
{
    return new ConfigurationErrorsException(
        String.Format
        (
        CultureInfo.CurrentCulture,
        Properties.Resources.MissingConfigSetting,
        name
        )
        );
}

Answer 4

Qu'en est-il System.Configuration.SettingsPropertyNotFoundException ?

Answer 5

ConfigurationErrorsException est l'exception correcte à lancer dans la situation que vous décrivez. Une version antérieure de la documentation MSDN pour le programme ConfigurationErrorsException est plus logique.

http://msdn.microsoft.com/en-us/library/system.configuration.configurationerrorsexception(VS.80).aspx

Le résumé et les remarques antérieures de MSDN sont les suivants :

• L'exception qui est levée lorsqu'une erreur du système de configuration de configuration.
• Le site ConfigurationErrorsException L'exception est levée lorsqu'une erreur se produit pendant que les informations de configuration est en cours de lecture ou écrites.