2009-11-24 8 views
0

Si j'ai un tableau ou d'une liste générique ou même un dictionnaire et je veux d'abord faire quelques vérifications pour voir si l'objet est valide, dois-je:Vérification des collections sur nulls

  1. Vérifier null
  2. Il suffit de cocher pour someCollection.count> 0
  3. deux

est-ce que je vérifie pour null puis vérifier le nombre ou vérifie pour le nombre assez bon et je ne ont pas besoin de vérifier null d'abord? Mon problème avec la POO et le C# est souvent de savoir quand vérifier les valeurs nulles par rapport aux collections. Et si c'est nul, alors que retourner si c'est null et que vous essayez de renvoyer un item dans cette collection à travers une propriété comme exemple.

Répondre

1

Vous ne pouvez pas vérifier Count sur une collection nulle.

Une collection vide et une collection nulle sont deux choses différentes. Vous devriez donc vérifier les deux, sinon, toujours initialiser vos collections afin de ne jamais rencontrer de problèmes nuls. Ou pour une solution simple, il suffit de retourner une nouvelle collection, puis laissez votre code appelant gérer la vérification du compte.

List<Type> someCollection = new List<Type(); 

if(someCollection == null) 
    return new List<Type>(); 
+0

bien que faire si ce code d'appel est dans votre balisage? Je ne veux pas d'un tas de logique dans mon balisage pour faire des vérifications de compte, etc. mais la méthode qui fait référence à cette propriété a besoin d'un objet de retour, qu'il soit nul ou non. Comment gérer ceci est mon point de douleur. – PositiveGuy

+0

Dites-vous que votre propriété a besoin d'un champ d'appui? Alors juste ce que j'ai suggéré et ai le champ de support initialisé à une nouvelle instance de la liste. – Brandon

1

Le nombre ne fonctionnera pas sur les objets NULL.

Voici un code de plaque de la chaudière, vous pouvez utiliser:

Debug.Assert(collection != null); 
Debug.Assert(collection.Count > 0); 
if (collection == null) { 
    throw new ArgumentNullException("collection"); 
} 
if (collection.Count == 0) { 
    throw new ArgumentException("collection should have at least one member"); 
} 

assertive est vraiment important et devrait être pratiqué par devs plus .Net. L'écrasement anticipé peut être la clé de l'écriture de code robuste.

S'il y a des paramètres qu'une méthode que vous écrivez ne devrait jamais être passée, il peut être préférable de planter à ce moment-là plutôt que d'écrire des données corrompues dans la base de données.

Vous avez également besoin d'un mécanisme de journalisation robuste afin de pouvoir enregistrer toutes les choses qui sont en train de se passer.

+0

Les assertions servent à vérifier les conditions qui doivent être vraies. Elles ne sont donc pas vraiment utiles lors de la validation d'arguments dans des méthodes publiques comme celle-ci. – Lee

+0

Êtes-vous en train de dire que les méthodes publiques n'ont pas de conditions préalables qui doivent être vraies? Gardez à l'esprit lors de la compilation en version toutes ces affirmations disparaissent. C'est un outil pour vous aider à rester honnête tout en écrivant votre code. Cela force le débogueur à vous harceler. –

+0

Les conditions préalables à la méthode sont appliquées en lançant des exceptions ici pour que les assertions soient redondantes. Je suis d'accord en général que les affirmations sont sous-utilisées cependant. – Lee

0

Lorsque vous avez le contrôle sur la création de ces collections, vous pouvez rendre votre API plus facile à utiliser par jamais retournant null. S'il n'y a pas d'éléments, renvoyez simplement une collection vide. Si la performance est une préoccupation, vous pouvez créer une seule instance statique et toujours la retourner, ou utiliser un EmptyEnumerator.

+0

oui, la performance est une préoccupation. Nous sommes un site de commerce électronique qui reçoit 500 000 visites uniques par mois – PositiveGuy