OK, nouveau codeur ici à la recherche d'un peu de perspicacité à ce problème. J'ai donc un pour la boucle comme ça commence comme ceci:
for (int i = 0; i < rowHandles.Length; i++)
{
.........code....
}
8 Réponses :
Si le problème est que Rowhandles code> peut être NULL code> Ajoutez simplement une vérification explicite de celle qui vous empêche d'exécuter l'instruction code> pour code>. if ( rowHandles != null ) {
for ( int i = 0; i < rowHandles.Length; i++ ) {
...
}
}
Merci, je me sens gentil de stupide parce que je l'ai essayé de la manière opposée: pour (...) {Si (Rowhandles! = NULL)} et cela n'a pas fonctionné, je ressemble à la tête, on dirait que j'avais le droit idée juste une mauvaise exécution. Je vais y arriver! Merci pour votre contribution!
@Nard, ne me sent pas stupide. Les erreurs sont la meilleure façon d'apprendre et nous avons tous fabriqués beaucoup d'entre eux.
Je vais à ce sujet; Je vois beaucoup de code de contrôle nul qui cache des bugs parce que les développeurs ne sont pas disposés à découvrir pourquoi quelque chose est null. Dans ce cas, on dirait que NULL n'est pas valide, alors je ne suis pas sûr de permettre à une null est une bonne idée. Je préférerais désactiver le bouton et ne pas laisser la vérification nulle. Met le fardeau de l'appelant, mais vous échouerez immédiatement si quelqu'un l'appelle avec des rangées en train d'être nulle. Des pensées?
C'est pas Rowhandles.length qui est NULL, c'est Rowhandles lui-même.
Une solution commune serait:
Le problème est que le bouton Suppr peut être cliqué lorsqu'il n'y a pas de lignes à gauche, de sorte que la longueur de rangée est égale à null.
C'est faux. Lorsqu'il y a 0 éléments, la longueur est réglée sur 0. Qu'est-ce que NULL est probablement des rangées. Vous devez gérer cette condition avant d'entrer dans votre boucle.
Modification de un de cette façon, à condition que l'objet de la ligne complète ne soit pas null (une vérification nulle rapide peut vérifier ceci). Sur tous les articles, et s'il n'y a pas d'articles, vous ne iriez pas du tout. foreach boucle:
S'il n'y a pas de rangées à gauche, la longueur de la longueur sera zéro non nulle. Si vous vous débarrassez des rangées de la boucle après la boucle, vous pouvez simplement faire:
if (rowHandles != null)
{
for (int i = 0; i < rowHandles.Length; i++)
{
// Code
}
}
On dirait que la longueur n'est pas la mince qui est null. Il s'agit plutôt de null et que vous obtenez une exception nulle lorsque vous essayez d'accéder à la propriété de longueur.
if(rowHandles != null)
{
//for loop
}
Je vous suggère d'essayer autant que possible de coller au Principe de responsabilité unique , dans que vous laissez le code faire ce qu'il est destiné à faire et à gérer les erreurs ailleurs.
C'est logique pour moi que Si vous choisissez toujours de le gérer dans le corps du code, vous référencez, l'une des solutions suggérées fonctionnera. Rowhandles est utilisé ailleurs, vous devriez donc centraliser le processus de vérification s'il s'agit ou non null .
Un principe important ici est Ne jamais gérer une exception que vous auriez pu empêcher la première place . Vous ne devriez jamais jamais gérer une exception de référence nulle; Une exception de référence nulle indique un bogue dans votre programme qui doit être corrigé, et non une conception attendue qui devrait être piégée et ignorée. Soit un code d'écriture qui garantit que la valeur n'est pas nulle ou détecte qu'il est null et ne la déréférence pas.
En dehors de cela étant une mauvaise pratique, laissant une exception de référence nulle se produire (puis la capturer) entraîner des problèmes d'état des programmes? Par exemple, je sais que certaines exceptions peuvent corrompre l'état du programme, mais le temps d'exécution .Net s'assure-t-il que Null-Référence ne fait pas cela?
@Matt: lire, écrire ou invoquer une référence null ne change pas d'état; L'exception arrive toujours avant que tout ce qui puisse être écrit.
Vous avez oublié de mentionner Cornell dans votre message.