Referencia de objeto no establecida en una instancia de un objeto: ¿cómo encontrar el nombre del objeto ofensivo en la excepción?

Question

Esta es la ruina de mi existencia de programación. Después de implementar una aplicación, cuando aparece este error, no hay cantidad de depuración que indique qué objeto no se creó una instancia. Tengo la pila de llamadas, eso es genial, me dice más o menos dónde está el objeto, pero ¿hay alguna forma de que .NET me diga el nombre real del objeto?

Si los detecta durante la depuración, por supuesto, el programa se deshace de la criatura ofensiva, pero si sucede después de que el programa está en libertad, buena suerte.

Tiene que haber una manera.

He explorado las excepciones devueltas en estas instancias y simplemente no hay nada útil.

Answer 1

No, no es posible. La excepción ocurre porque una referencia es nula y las referencias no tienen nombres. Las variables y los miembros de clase/estructura tienen nombres, pero no es seguro que la referencia se almacene en cualquiera de esos. La referencia podría ser, por ejemplo, se creará de esta manera:

someObject.GetInstance().DoSomething(); 

Si el método devuelve null GetInstance, hay una excepción de referencia nula cuando intenta utilizar la referencia a llamar DoSomething. La referencia es solo un valor de retorno del método, no está almacenada en una variable, por lo que no hay nada para obtener un nombre.

Si tiene información de depuración en el ensamblado compilado, obtendrá el número de línea en el seguimiento de pila en la excepción, pero eso es lo más cercano que puede obtener.

Answer 2

Este es uno de esos casos en los que realmente necesita conectarse a la aplicación y recorrer el área general del código ofensivo para averiguar de dónde proviene esa referencia nula.

Answer 3

Creo que actualmente lo mejor que puedes conseguir es la línea no.

StackTrace: at test_003.Form1.button1_Click(Object sender, EventArgs e) in C:\Documents and Settings\...\Projects\test_003\test_003\Form1.cs:line 52

Si hacen algo en el futuro acerca de este problema, que sería genial.

Answer 4

NullReferenceException es el más malvado de todas las excepciones en una aplicación. Significa que una referencia posiblemente nula no se verificó para un valor nulo antes de acceder.

Es malo, porque el tiempo de ejecución no puede determinar lo que esperaba encontrar en la referencia, por lo que no puede decirle qué es precisamente lo que no se pudo desreferenciar.

El seguimiento de la pila es su único amigo en esta excepción, donde al menos puede identificar qué método arrojó la excepción. Si su código es lo suficientemente claro, debe identificar una pequeña cantidad de código para verificar.

Además, si está ejecutando una compilación de depuración y tiene la información de depuración con los ensamblajes, incluso obtendrá números de línea fuente en el seguimiento de pila, para que pueda saber exactamente en qué línea falló el método.

---

La verdadera respuesta es evitar que esta excepción de vez ser lanzado.Es un indicador de que algunos códigos estaban mal escritos, y no se maneja el escenario donde la referencia era null.

Si usted tiene un método que se llama donde tiene que hacer algo con un argumento de tipo de referencia que necesita ser referenciada des en algún momento, la verificación de null y tirar ArgumentNullException, indicando el nombre del parámetro:

if(parameter == null) 
    throw new ArgumentNullException("parameter"); 

Si está realizando una operación dentro de una clase y una propiedad ajustable se puede ajustar a null, comprobar antes de-referencia a ella y lanzar un InvalidOperationException indicando el problema:

if(Property == null) 
    throw new InvalidOperationException("Property cannot be null."); 

También debe asegurarse de que todos los métodos que está llamando que pueden devolver tipos de referencia garanticen el retorno de un valor. Para todos aquellos que no lo son, haga comprobaciones similares para null y maneje la caja adecuadamente.

EDIT:

Para aclarar, no estoy sugiriendo que realizar una prueba de todas las variables de tipo referencia antes de-referencia de la misma. Eso sería una locura.

Se trata de entender dónde se puede asignar una variable null y donde no se puede asignar. Si asigna un campo privado en una clase a un valor no nulo en el constructor, y el valor nunca se asigna de nuevo, no necesita verificar si el valor es null; el diseño de tu clase se ha asegurado de que nunca pueda ser.

Un objeto bien diseñado limitará las oportunidades para los valores null asignados y usará el código de protección cuando corresponda para arrojar excepciones cuando un valor null puede estar presente.