Una mejor manera de manejar NullReferenceExceptions en C#

Question

Recientemente tuve un error de codificación donde bajo ciertas condiciones una variable no se inicializaba y obtenía un NullReferenceException. Esto demoró un tiempo en depurarse ya que tuve que encontrar los bits de datos que generarían esto para recrear el error ya que la excepción no da el nombre de la variable.

Obviamente, pude verificar cada variable antes de su uso y arrojar una excepción informativa, pero ¿hay alguna forma mejor (leer menos codificación) de hacer esto? Otro pensamiento que tuve fue el envío con los archivos pdb para que la información del error contenga la línea de código que causó el error. ¿Cómo otras personas evitan/manejan este problema?

Gracias

Answer 1

En primer lugar: no hacer demasiado en un solo estado. Si tiene un gran número de operaciones de desreferenciación en una línea, va a ser mucho más difícil de encontrar al culpable. El Law of Demeter ayuda con esto también - si tiene algo como order.SalesClerk.Manager.Address.Street.Length, entonces tiene muchas opciones que recorrer cuando obtiene una excepción. (Estoy no dogmática sobre la Ley de Demeter, pero todo con moderación ...)

En segundo lugar: Prefiero fundición sobre el uso de as, a menos que sea válida para el objeto a ser un tipo diferente, que normalmente implica una verificación nula inmediatamente después. Así que aquí:

// What if foo is actually a Control, but we expect it to be String? 
string text = foo as string; 
// Several lines later 
int length = text.Length; // Bang! 

Aquí se conseguiría un NullReferenceException y, finalmente, lo cifran en text siendo nula - pero entonces no sabría si eso es porque foo era nula, o porque era un tipo inesperado. Si debe muy, muy ser un string, a continuación, fundido en su lugar:

string text = (string) foo; 

Ahora usted será capaz de notar la diferencia entre los dos escenarios.

En tercer lugar: como han dicho otros, valide sus datos, generalmente argumentos a API públicas y potencialmente internas. Hago esto en suficientes lugares en Noda Time que tengo una clase de utilidad para ayudarme a declutter el cheque. Así, por ejemplo (de Period):

internal LocalInstant AddTo(LocalInstant localInstant, 
          CalendarSystem calendar, int scalar) 
{ 
    Preconditions.CheckNotNull(calendar, "calendar"); 
    ... 
} 

Usted debe documento lo que puede y no puede ser nulo, también.

Answer 2

Lamento decir que siempre realizaré una verificación para verificar que cualquier objeto que estoy usando en un método en particular no sea nulo.

Es tan simple como

if(this.SubObject == null) 
{ 
    throw new Exception("Could not perform METHOD - SubObject is null."); 
} 
else 
{ 
... 
} 

lo contrario, no se me ocurre ninguna manera de ser exhaustiva. No tendría mucho sentido para mí no hacer estos controles de todos modos; Siento que es solo una buena práctica.

Answer 3

En primer lugar debe siempre validar sus entradas. Si null no está permitido, arroje un ArgumentNullException.

Ahora, sé cómo puede ser doloroso, por lo que podría buscar herramientas de reescritura de ensamblaje que lo hagan por usted.La idea es que usted tendría un tipo de atributo que marcaría los argumentos que no pueden ser null:

public void Method([NotNull] string name) { ... 

Y la re-escritura sería llenar los espacios en blanco ...

O una simple extensión método podría hacer más fácil

name.CheckNotNull(); 

Answer 4

en muchos casos es casi imposible para planificar y dar cuenta de cada tipo de excepción que podría ocurrir en cualquier punto dado en el flujo de ejecución de la aplicación. La codificación defensiva es efectiva solo hasta cierto punto. El truco es tener una pila de diagnósticos sólida incorporada en su aplicación que pueda brindarle información significativa sobre los errores y bloqueos no controlados. Tener un buen controlador de nivel superior (último recurso) en el nivel del dominio de la aplicación ayudará mucho con eso.

Sí, enviar los PDB (incluso con una compilación de versión) es una buena forma de obtener un seguimiento completo de la pila que puede identificar la ubicación exacta y las causas de los errores. Pero cualquiera que sea el enfoque de diagnóstico que seleccione, debe integrarse en el diseño de la aplicación para comenzar (idealmente). Volver a adaptar una aplicación existente puede ser tedioso y requerir mucho tiempo o dinero.

Answer 5

Si sólo están buscando una forma más compacta de código en contra de tener referencias nulas, no pase por alto el operador nulo coalescencia ??MSDN

Obviamente, depende de lo que está haciendo, pero se puede utilizar para evitar declaraciones extra if.