Quel exception à générer à partir d'une propriété setter?

J'ai une chaîne de propriété qui a une longueur maximale exigence parce que les données sont liées à une base de données. Quel exception dois-je lancer si l'appelant tente de définir une chaîne dépassant cette longueur?

Par exemple, ce code C#:

public string MyProperty
{
    get
    {
        return _MyBackingField;
    }
    set
    {
        if (value.Length > 100)
            throw new FooException("MyProperty has a maximum length of 100.");

        _MyBackingField = value;
    }
}

J'ai considéré ArgumentException, mais il ne semble pas approprié. Techniquement, c'est une fonction - MyProperty_set(string value) - si un cas de ArgumentException peuvent être faites, mais il n'est pas d'être appelé comme une fonction aux yeux des consommateurs - c'est sur le côté droit de l'opérateur d'affectation.

Cette question pourrait également être étendu pour inclure tous les types de données de validation dans les accesseurs de propriété, mais je suis particulièrement intéressé dans le cas ci-dessus.

InformationsquelleAutor lc. | 2009-03-11

c#exception properties validation

46

Jetez un oeil à travers mscorlib.dll avec Réflecteur, dans une situation similaire à un tel Système.Chaîne de caractères.StringBuilder.La capacité de Microsoft à l'utilisation ArgumentOutOfRangeException() similaire à:
```
public int PropertyA
{
    get
    {
        return //etc...
    }
    set
    {
        if (condition == true)
        {
            throw new ArgumentOutOfRangeException("value", "/* etc... */");
        }
        //... etc
    }
}
```
- Btw, Mono déclenche une exception d'argument dans ce cas...
- "ArgumentOutOfRangeException - L'exception est levée lorsque la valeur d'un argument est en dehors de la plage autorisée de valeurs tel que défini par la méthode invoquée" .... omi, Mono devraient fixer leur code.
- confirmé ici: referencesource.microsoft.com/#mscorlib/system/text/...
InformationsquelleAutor Richard Slater
16

Pour moi ArgumentException (ou un enfant) a plus de sens, parce que l'argument (valeur) que vous avez fourni n'est pas valide, et c'est ce que ArgumentException a été créé pour.

InformationsquelleAutor Davide Vosti
10

Je ne lance pas d'exception à tous. - Je plutôt permettrait une chaîne de caractères de longueur quelconque et ensuite avoir une autre "Valider" méthode de la classe qui est appelée avant de l'enregistrer. Il y a un certain nombre de scénarios, en particulier si vous utilisez la liaison de données où lancer des exceptions de la propriété setters pouvez-vous obtenir dans un désordre.

La difficulté à lever des exceptions de accesseurs de propriété est que les programmeurs oubliez pas de les attraper. Ça dépend comment nettoyer vous vous attendez à ce que les données que vous arriver à être. Dans ce cas, je voudrais s'attendre à de longues longueurs de chaîne pour être courant de ne pas exceptionnel, et en tant que tel à l'aide d'une exception serait "contrôle de flux avec des exceptions".

Pour citer le Microsoft Les lignes Directrices de conception pour le Développement de Bibliothèques de Classe:

Ne pas utiliser les exceptions pour les flux normal
de contrôle, si possible. Sauf pour
les défaillances du système et des opérations avec
potentiel des conditions de course, cadre
les concepteurs doivent concevoir les Api de sorte que
les utilisateurs peuvent écrire du code qui n'a pas
lancer des exceptions. Par exemple, vous pouvez
fournir un moyen de vérifier les conditions préalables
avant d'appeler un membre de sorte que les utilisateurs
pouvez écrire du code qui n'est pas à jeter
des exceptions.
- Alors que personnellement, je ne suis pas du tout d'accord (la Validation est le travail de l'incubateur après tout, il n'y a aucun intérêt à faire autre chose que de la simple champ = valeur; return champ; des getters/setters - je voudrais que vous soulevez le point de liaison de données qui, de fait, pouvez-vous obtenir dans un désordre.
- Exception jeter dans les accesseurs de propriété est OK pour le faire, je ne voudrais pas lancer des exceptions à la propriété des getters bien.
- Retarder le lancement d'une exception ne vous permettra pas de rattraper le infractor. Aussi, si un programmeur oublie d'attraper une exception alors il va sauter sur son visage au lieu de bouillonnement par inadvertance.
- Je suppose que cela dépend de ce que vous êtes de la conception de la classe. Dans le cas où vous vous attendez à DataBind à des objets de la classe, vous ne voulez pas faire sauter lorsque l'utilisateur tape dans une à de nombreux personnages. La Mise En Œuvre Du Système.ComponentModel.IDataErrorInfo est la façon standard autour de cela. Dans le setter au lieu de lancer une exception vous de définir un indicateur interne appelé quelque chose comme IsMyPropertyToLong. Plus tard, vous utilisez cette option pour retourner le message d'erreur correct à partir de ce[chaîne]
- Heureux de voir l'extrait du guide de conception. J'aime l'idée que le setter de la lance, et l'erreur est immédiatement apparent. En ce qui concerne l'écriture de code qui ne jetez pas une exception, j'aime la TryParse un modèle ou dans ce cas bool TrySet(valeur) qui ne serait pas le jeter.
- ArgumentException et ArgumentOutOfRangeExceptions sont "Boneheaded Exceptions" et ils sont légitimement utilisé ici pour vérifier les contraintes. Si l'utilisateur obtient ces évitables exceptions que c'est un bug dans leur code.
- Je suis heureux de voir cette alternative mentionnée, mais il est bon de jeter une exception dans ce cas. Après tout, il est assez simple de définir la zone de texte de longueur maximale. Le Validate méthode est une bonne approche pour la validation des règles qui dépendent d'autres propriétés. Vous ne pouvez pas savoir les propriétés se mettre tout d'abord, il est donc préférable de vérifier à la fin.
InformationsquelleAutor Martin Brown
6

Rappelez-vous comment de nombreux problèmes dans le domaine de l'informatique ont résolu par l'ajout d'un niveau supplémentaire d'indirection?

Une approche serait de créer un nouveau type, FixedLengthString, dire. Il serait instances de que type de valider les longueurs de chaînes ils sont initialisées avec - avec un opérateur de conversion de type de conversion à partir d'une chaîne simple. Si votre propriété setter prend un tel type de son argument, alors toute violation de devenir une conversion de type exception au lieu d'un argument/propriété d'exception.

Dans la pratique, j'ai rarement le faire. Ça sent un peu de la prise OO trop loin - mais dans certains cas, il peut être une technique utile, donc je le mentionne ici par souci d'exhaustivité.
- Comment voulez-vous faire face avec le passage d'un FixedLengthString fixé à max 100 caractères d'une propriété nécessaire une FixedLengthString fixé à max 50 caractères?
InformationsquelleAutor philsquared

public IPAddress Address
{
    get
    {
        return address;
    }
    set
    {
        if(value == null)
        {
            throw new ArgumentNullException("value");
        }
        address = value;
    }
}

via MSDN

Bon point, même si c'est spécifique pour la valeur null. Cependant, il prend en charge l'utilisation de la ArgumentException de la série, donc +1 pour la référence.

InformationsquelleAutor Evgeniy Krechun

-1

Vous pouvez utiliser InvalidOperationException. C'est un compromis. Je ne voudrais pas ennuyer à l'aide d'un ArgumentException soit.

InformationsquelleAutor Sascha
-2

Essayez d'utiliser les exceptions existantes où que possible. Dans ce cas, l'utilisation d'exception InvalidOperationException parce que la valeur entrante est d'amener l'objet dans un état incohérent. Personnalisé des exceptions peuvent être créés lorsqu'une manipulation spécifique à l'exception personnalisée est nécessaire. Dans ce cas, vous ne lève une exception avec un peu de texte, donc de l'utiliser à l'exception InvalidOperationException.

Lors du lancer de la InvalidOperationException montrer la valeur qui a été transmis à cette setter.
- Bien sûr, vous pouvez avoir le meilleur des deux mondes et de créer votre propre type d'exception qui en découle, disons, InvalidOperationException. Bien sûr, vous payez toujours un peu de code supplémentaire et la complexité du code. C'est un faible coût, mais après la pesée, vous pouvez toujours considérer qu'elle n'est pas la peine
- InvalidOperationException ne devrait pas être soulevées dans le présent cas. Ce qui est mauvais, c'est la valeur, non pas l'opération de réglage de la valeur.
InformationsquelleAutor Patrick Peters

Vous devez vous connecter pour publier un commentaire.