Devrais-je de la CA1062: Valider les arguments des méthodes publiques?

Question

Je l'ai récemment mis à jour mon projet à Visual Studio 2010 à partir de Visual Studio 2008.

Dans Visual Studio 2008, cette règle d'analyse du code n'existe pas.

Maintenant, je ne sais pas si je devrais utiliser cette règle ou non.

Je construis une bibliothèque open source donc il semble important de garder les gens à l'abri de faire des erreurs. Cependant, si tout ce que je vais faire est de lancer ArgumentNullException lorsque le paramètre est null, il semble que l'écriture de code inutile puisque ArgumentNullException sera jeté même si je ne vais pas écrire ce code.

EDIT: En outre, il y a un problème de performance qui doit être pris en compte. Vérification de null dans chaque méthode publique peut entraîner des problèmes de performance.

Devrais-je supprimer cette règle ou les violations corriger?

Answer 1

Cela dépend. La convention lors de l'utilisation ArgumentNullException est d'inclure le nom de l'argument null dans la description. Ainsi, l'appelant saura exactement ce qui a mal tourné.

La source d'un NullReferenceException (qui est ce qui se passera si vous ne validera pas) peut être facile à repérer, mais si la méthode est complexe, il peut être plus difficile. Vous pouvez finir à une ligne de code où plusieurs références pourraient être nulles.

Personnellement, je préfère avoir des méthodes publiques jettent ArgumentNullException si elles ne peuvent pas gérer l'entrée nulle pour l'argument donné, car il permet, peu importe la façon dont la méthode est mise en œuvre pour un comportement cohérent.

En réponse à modifier: À mon avis, il est plus important de fournir un ensemble cohérent d'interfaces avec quelques surprises que l'optimisation de chaque ligne de code. Je pense que dans la plupart des cas, les frais généraux de performance du chèque nul ne sera pas significatif. Si elle ne se révéler un problème (comme dans le profilage dit donc) je considérerais le changer. Sinon, je ne considère pas un problème à ce stade.

Answer 2

Nous gardons cette règle parce que nous avons décidé qu'il était toujours préférable de vérifier les paramètres de leur première entrée dans votre code. De cette façon, lorsque la personne utilisant votre code obtient l'exception du contexte dans ce sera mieux. Quelqu'un qui n'a pas votre code source par exemple verra que l'exception a été levée dans votre code et peut déposer un rapport de bogue contre vous pour cela perdre votre temps et le leur.

Answer 3

à mon humble avis n ° Vérification des valeurs nulles va presque jamais être le goulot d'étranglement dans votre application. (Et dans celui d'un million de cas où il est important, vous trouverez avec votre profileur et supprimer ce un cas).

L'autre question qui devrait se former dans votre esprit est « est throw new NullReferenceException () vraiment la meilleure façon de gérer l'erreur? » Souvent, vous pouvez gérer les choses mieux que cela (même si seulement de fournir un meilleur rapport d'erreur à l'utilisateur et / ou vous-même à des fins de débogage). Dans de nombreux cas, le code peut gérer grâce nulls, ce qui rend inutile pour que cela soit une erreur du tout.

modifier

Pour répondre à votre édition: contrôles Null vraiment ne prennent pas longtemps. Les frais généraux pour appeler simplement une méthode sera des dizaines sinon des centaines de fois plus qu'un chèque nul. Le seul endroit où un chèque nul fera une différence significative est dans une grande boucle serrée où vous faites très peu de choses. Cette situation ne se produit pas très souvent -. En général, vous vérifierez un nul et puis faire quelque chose relativement cher avec cette référence

Il n'y a pas de situation où un accident ou d'échec est une bonne chose. Il est toujours préférable de « ralentir votre bas de l'application » avec des contrôles nuls que de planter et de perdre les données de vos clients.

Donc, ne pas optimiser prématurément votre code. Écrire bien, être maintenable et robuste, puis profil pour voir où sont les goulots d'étranglement. J'ai la programmation depuis 28 ans, très libérale avec les chèques nuls, et ai jamais trouvé qu'un chèque nul a été la cause d'un problème de performance. Habituellement les choses est comment faire beaucoup de travail inutile dans une boucle, en utilisant un O (n ^ 3) algorithme où une O approche (n ^ 2) est possible, à défaut de mettre en cache les valeurs chères à compute, etc.