Eh bien, il y a quelques mois, j'ai demandé Une question similaire à propos de C et C ++ , mais je paie plus d'attention à C # récemment en raison de la chose" Windows Phone ".
Donc, en C #, il faut-il prendre la peine de vérifier contre NULL à la méthode des limites? Je pense que cela est différent de celui de C et C ++, car en C # One peut généralement déterminer si une référence donnée est valide - le compilateur empêchera d'éviter des références non initialisées n'importe où et, par conséquent, la seule erreur restante possible est pour qu'elle soit nulle. . En outre, il existe une exception spécifique définie dans la framework .NET pour ces choses, le Argumentnullexception , qui semble codifier ce que les programmeurs pensent qu'ils devraient être obtenus lorsqu'une NULL invalide a été adoptée.
Mon opinion personnelle est une fois de plus qu'un appelant faisait cela est cassé et que ledit appelant devrait avoir NRES jeté à eux jusqu'à la fin des jours. Cependant, je suis beaucoup moins sûr de cela que je suis dans le code natif de Code Land - C # a un style de programmation différent dans des lieux par rapport à C ou C ++ à cet égard.
Alors ... Si vous voulez vérifier les paramètres NULL dans les méthodes C #?
4 Réponses :
Oui, vérifiez-les. Utilisez de préférence des contrats de code pour indiquer à l'appelant que vous avez besoin de paramètres non nuls ceci est particulièrement avantageux car le client peut voir exactement ce qui est requis des paramètres. si Vous ne pouvez pas utiliser les contrats de code, utiliser une clause de garde échoue rapide.
sera contrat.requires (barre! = null); drapeau foo (null); au moment de la compilation que je doute que cela aura l'avantage d'utiliser quelque chose comme Ceci par rapport à une simple vérification nulle avec si ?
D'où viennent le contrat / la garde? Je ne connais pas ces bits. : / Est-ce que cela s'applique aux méthodes publiquement exposées ou à des méthodes intra-composantes également?
@Bill Oneal: le contrat de code est dans .NET 4.0 dans le System.Diagnostics.Contractes Espace de noms. Guard est une classe d'utilités courante que les personnes ont leur propre version de mais essentiellement, elle jette simplement l'exception spécifiée dans le paramètre de type si la condition est satisfaite.
@Bala R: Vous pouvez faire une vérification statique et cela devient une partie de la documentation.
Les contrats / la partie protectrice distraient un peu de la réponse. Comment vous vérifiez dépend de plusieurs facteurs. J'aime les contrats mais cela ne sera pas acceptable partout (encore).
Je pense qu'il est préférable de lancer un La vérification null est alors la responsabilité du client qui crée un code plus maintenu sur les deux les deux (souvent une situation gagnant-gagnant) ... au moins c'est ce que je ressens. argumentnulxception (ou utilisez un contrat comme Jason suggère ) si votre méthode ne veut pas qu'un paramètre particulier soit null. C'est un témoignage bien meilleur par le contrat au client de ne pas transmettre NULL en premier lieu lors de l'appel de votre méthode.
Pensez-vous que cela est un must pour les méthodes de bibliothèque exposées uniquement, ou en interne aussi?
@Billy: Ne faites cela que pour les méthodes de bibliothèque exposées. Seules les méthodes marquées comme public doivent faire la validation des paramètres de n'importe quel type. Il s'agit d'une dépense inutile pour les méthodes internes et privées, c'est l'une des raisons d'avoir des méthodes qui ne font pas partie de l'interface en premier lieu.
@Cody: Et si la classe elle-même n'est pas exposée? Par exemple. La classe est interne .
@Billy: C'est vraiment la même chose. Le niveau d'accès de la classe médiane le niveau d'accès de ses membres individuels. Si la classe ne peut pas être utilisée en dehors de la bibliothèque, cela ne fait pas partie de son interface publique. Vous peut envie d'implémenter la validation des paramètres simplement pour une commodité ou une minutie à l'intérieur de la bibliothèque, mais ce n'est pas strictement nécessaire, car le code interne peut être strictement vérifié. Le seul problème est que les classes seront exposées à l'extérieur, utilisées dans des situations où les appelants ne peuvent pas être vérifiés et testés de manière approfondie.
C'est une bonne pratique pour valider tous les paramètres au moins dans des méthodes publiques. Cela aide à localiser des bugs plus rapidement et aide également tout en lisant le code, car il décrit le contrat de la méthode.
Nous avons mis en place une classe statique par exemple: assercipabilitée qui a un tas de méthode de paramètre et de validation d'état. Je crois que certaines personnes appellent de telles classes gardien .
Alors ... Si vous voulez vérifier les paramètres NULL dans les méthodes C #?
Oui, à moins bien sûr quand
null est autorisé.Une meilleure perspective: Vous devriez toujours vérifier pour valeurs de paramètres valides . Parfois, une référence est autorisé à être nul, parfois un
int doit être> = 0 ou une chaîne ne peut pas être NullOrWhiteSpace.Il est donc une bonne pratique de commencer chaque méthode avec un bloc de validation des paramètres.
A partir de là il y a quelques choix. La validation des méthodes internes / privées est généralement considérée comme moins critique, et pour des raisons de performance, il peut être subordonné (ou même omis).
Validation à une limite est généralement laissée dans construit Release. Il y a très peu de raisons de se tourner jamais hors tension.
La plupart des projets utiliseront des classes d'aide pour la validation, afin de minimiser le codage répétitif à l'intérieur des méthodes. Un très bon mais pas encore très populaire boîte à outils est intégré dans la classe de System.Diagnostics.Contracts. Les outils de code-contrats ont beaucoup de paramètres relatifs à la validation des paramètres.
Voir, je suis fortement en désaccord pour le bit de "Vérifier les paramètres valides" - dans le cas général qui n'est pas possible ou pratique, même dans des environnements aussi restreints que le CLR.
Que
arguments S semble porter deux significations ici, hein? : P@BoltClock: lol - j'espère pas. Je ne veux pas commencer à faire des flammes sur ces choses, mais ils semblent se passer de toute façon.
@downvoter: Avez-vous un problème spécifique avec cette question?