Je suis curieux Comment maintiendriez-vous votre code une fois que vous avez lancé un En gros, j'ai un énoncé de commutation comme celui-ci: p> System.componentmodel.invalidenumargumentException code>. switch (enumValue)
{
case MyEnum.Value1:
break;
case MyEnum.Value2:
break;
default:
throw new InvalidEnumArgumentException();
}
6 Réponses :
Je n'utiliserais pas cette exception que vous utilisez dans ce contexte. En vertu d'Enumvalue étant de type myenum (je présume?) Il ne peut jamais contenir une valeur d'énumération non valide. Si vous avez des commutateurs basés sur la valeur de l'énum, qui doit échouer s'ils ne reconnaissent pas la valeur, vous devez lancer une exception appropriée (peut-être une erreur d'argument normale?) Mais dans la plupart des cas, je suppose que vous Laissez le code exécuter ne rien faire pour une valeur d'énorme inconnue.
Ceci est une erreur. Selon Cet ajout aux directives de conception , "Il est légal de jeter une valeur entière dans une énorme valeur, même si la valeur n'est pas définie dans l'énum.".
Bien sûr, un Enum peut être invalide. Vous pouvez lancer un numéro qui n'est pas l'une des valeurs d'énumération à un type Enum . Ou cela pourrait être causé par une énumération définie dans un assemblage différent qui a été mis à jour avec une énumération élargie.
Eh bien je n'ai jamais. On dirait que j'ai appris quelque chose de nouveau aujourd'hui. :-)
Vous utilisez l'exception dans une mauvaise manière:
Cette exception est lancée si vous passez une valeur d'énumération non valide à une méthode ou lors de la définition d'une propriété.
Ensuite, quelle exception devrait-elle être lancée?
J'utiliserais simplement une note notimpleedException - car je n'ai littéralement aucun code mis en œuvre pour traiter correctement la valeur de l'énorme nouvellement ajoutée.
Je pense que vous cherchez dans le mauvais contexte, si ceux-ci n'étaient pas énumés, mais certaines valeurs spécifiques fondées sur une règle d'entreprise, donc dans de tels cas que les règles augmentent les codes pertinents comme ceux-ci pour incorporer les nouvelles. Donc, si vous modifiez l'énum, vous devez vous approfondir des changements comme ceux-ci.
S'il y a de nombreux endroits avec de telles déclarations de commutation agissant sur le même énumé, on peut avoir une usine qui crée des objets polymorphes basés sur une valeur ENUM et déplacez cette fonctionnalité des commutateurs à des méthodes de cet objet.
Le problème que vous indique dépend du contexte, si une méthode reçoit une énumération comme argument, il doit spécifier quelles valeurs utilisent-elles et ce qu'elle fait avec une valeur d'énumération inconnue.
Si vous ajoutez plus d'options d'énumération dont vous avez besoin. Pour décider quoi faire, même si vous ne lançiez pas une exception dans le cas par défaut. p>
se rappelle que l'exception est spéciale, car vous pouvez transmettre n'importe quel entier comme une valeur d'énumération. P>
Par exemple: P>
enum Foo { A, B }
static int Bar(Foo f)
{
switch (f)
{
case Foo.A:
return 1;
case Foo.B:
return 2;
default:
throw new InvalidEnumArgumentException("f", (int)f, typeof(Foo));
}
}
static void Main()
{
Bar(Foo.A);
Bar((Foo)99);
}
Une légère amélioration de l'exemple si vous ne ciblez que le point de DOT 4.6 ou ci-dessus consiste à remplacer la chaîne "F" avec nomof (f) .
Pour valider la valeur d'énumération entrante Utilisez la méthode statique suivante ...
public void MyMethod(MyEnum e)
{
if (!Enum.IsDefined(typeof(MyEnum), e))
throw new InvalidEnumArgumentException("e", (int)e, typeof(MyEnum));
Si le myenum est étendu avec de nouvelles valeurs, le ! Enum.isdefinefin (typeof (myenum), e)) retournera vrai pour eux. Ce test ne fera donc jamais échouer.
@Spook mais il échouera si Myenum ne définit pas une entrée pour 0 et e obtient implicitement une valeur par défaut dans myenum e; MyMethod (E); ou lorsque le code définit le code E S numériquement. Le point est que c # lui-même ne force pas E une valeur valide pour myenum et, tout simplement, vous ne pouvez rien assumer.
Et si je décide d'ajouter plus de valeurs au myenum à l'avenir, par exemple, valeur3 et value4? Cela signifierait que je finirais de jeter une exception trompeuse. Comment puis-je empêcher cela?
Lorsque vous utilisez
InvalidénumargumentException La principale chose à comprendre est argument . En lançant l'exception, vous dites que l'argument pour la méthode était invalide. (InvalidénumargumentException dérive deArgumentException .) Il ne signifie pas nécessairement que la valeur n'était pas membre duEnum . Donc, je ne considérerais pas cela trompeur.