2010-10-29 23 views
6

Ok, nuevo codificador aquí buscando una pequeña idea de este problema. Así que tengo un bucle como que empieza así:Manejando una excepción nula C#

for (int i = 0; i < rowHandles.Length; i++) 
{ 
     .........code.... 
} 

rowHandles es una matriz int que contiene filas de datos. Este ciclo for tiene un código que borra las filas de datos cuando se hace clic en un botón de eliminar, para ser específico es un botón Eliminar de la barra de herramientas de la cuadrícula y está dentro del controlador de evento de clic del botón eliminar. El problema es que se puede hacer clic en el botón Eliminar cuando no quedan filas, por lo que rowHandles.Length es nulo. ¿Cómo evitaría que esto detenga el programa? ¿Hay algo que pueda agregar dentro del bucle for, en la declaración for loop, o fuera del bucle for para corregir esto? Tal vez un try catch? ¿Cómo se estructuraría esto alrededor de este problema/ciclo específico?

Gracias por toda su ayuda - Novato Coder

+0

Olvidó mencionar a Cornell en su publicación. –

Respuesta

10

Si el problema es que puede haber rowHandlesnull a continuación, sólo añadir una comprobación explícita de lo que le impide ejecutar la instrucción for.

if (rowHandles != null) { 
    for (int i = 0; i < rowHandles.Length; i++) { 
    ... 
    } 
} 

Otra opción sería deshabilitar el botón Eliminar por completo si no hay filas para eliminar. La operación no es válida, así que evítela desde el principio.

+0

Gracias, me siento un poco estúpido porque lo intenté de la manera opuesta: por (...) {if (rowhandles! = Null)} y eso no funcionó, así que me estaba rascando la cabeza, parece que tuve el idea correcta solo ejecución incorrecta. ¡Estaré ahí! ¡Gracias por tu contribución! –

+4

@Nard, no te sientas estúpido. Los errores son la mejor manera de aprender y todos hemos hecho muchos de ellos. – JaredPar

+0

Voy y vuelvo en esto; Veo un código de comprobación nulo que oculta errores porque los desarrolladores no están dispuestos a descubrir por qué algo es nulo. En este caso, parece que null no es válido, por lo que no estoy seguro de permitir una nula es una buena idea. Preferiría desactivar el botón y no dejar el cheque nulo. Le impone la carga a la persona que llama, pero fallará inmediatamente si alguien lo llama con rowhandlers siendo nulo. ¿Alguna idea? –

2

Es norowHandles.Length que es nulo, es rowHandles sí mismo.
Una solución común sería:

if (rowHandles != null) 
//Your loop here 
3

El problema es el botón de borrar puede hacer clic cuando no hay filas que quedan, por lo rowHandles.Length es igual a null.

Esto está mal. Cuando hay 0 elementos, Length se establece en 0. Lo que es nulo es probablemente rowHandles. Debe manejar esa condición antes de entrar en su ciclo.

0

Cambio a un bucle foreach:

foreach (var rowHandle in rowHandles) 
{ 
    // use rowHandle instead of rowHandles[i] 
} 

De esta manera, siempre todo el rowHandles objeto no es nulo (un cheque nulo rápida puede verificar esto) va a iterar sobre todos los artículos, y si no hay elementos , no iterarás en absoluto.

2

Si no quedan filas, rowHandles.Length será cero, no nulo. Si vas a deshacer de rowHandles después del bucle, a continuación, puedes hacer:

if (rowHandles != null) 
{ 
    for (int i = 0; i < rowHandles.Length; i++) 
    { 
      // Code 
    } 
} 

No hay necesidad de manejo de excepciones. Por otro lado, si permite que rowHandles cambie por otra cosa mientras se ejecuta ese ciclo, esa es otra historia.

1

Parece que la longitud no es la delgada que es nula. Más bien es rowHandles que es nulo y está obteniendo la excepción nula cuando intenta acceder a la propiedad Length.

if(rowHandles != null) 
{ 
    //for loop 
} 
1

yo sugeriría que intenta lo más posible a pegarse a la Single Responsibility Principle, en el que deja que el código hace lo que se pretende hacer, y manejar los errores en otros lugares.

Tiene sentido para mí que rowHandles se use en otro lugar, por lo que debe centralizar el proceso de comprobar si es o no null.

Si aún elige manejarlo en el cuerpo del código al que hace referencia, cualquiera de las soluciones sugeridas funcionará.

6

Un principio importante aquí es nunca maneje una excepción que podría haber prevenido en primer lugar. Nunca debe manejar una excepción de referencia nula; una excepción de referencia nula indica un error en su programa que debe corregirse, no un evento esperado que debe quedar atrapado e ignorado. Escriba código que garantice que el valor no sea nulo, o detecte que es nulo y no lo desreferencia.

+0

Además de ser una mala práctica, ¿dejar que ocurra una excepción de referencia nula (y luego detectarla) causa algún problema con el estado de los programas? Por ejemplo, sé que algunas excepciones pueden dañar el estado del programa, pero ¿el tiempo de ejecución .NET se asegura de que la referencia nula no haga esto? –

+0

@Matt: leer, escribir o invocar una referencia nula no cambia el estado; la excepción siempre ocurre antes de que se pueda escribir algo malo. –

+0

gracias por confirmar eso. –

Cuestiones relacionadas