c# - brother - referencia a objeto no establecida como instancia de un objeto wcf

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

Question

Esta es la perdición de mi existencia de programación. Después de desplegar una aplicación, cuando este error surge, ninguna cantidad de volcado de depuración le dice QUÉ objeto no fue instanciado. Tengo la pila de llamadas, eso es genial, me dice aproximadamente dónde está el objeto, pero ¿hay alguna forma de que .NET me diga el nombre real del objeto?

Si los atrapas mientras depuras, por supuesto, el programa se rompe en la criatura ofensora, 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 estos casos y no hay nada útil.

Answer 1

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 sobre este problema, sería genial.

Answer 2

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

Answer 3

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 esté almacenada en ninguno de ellos. La referencia podría por ejemplo crearse así:

someObject.GetInstance().DoSomething();

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

Si tiene información de depuración en el ensamblaje 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 4

NullReferenceException excepción NullReferenceException es la más perversa de todas las excepciones en una aplicación. Significa que una referencia posiblemente nula no se comprobó para un valor nulo antes de que se accediera.

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 exactamente lo que no se pudo referenciar.

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

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

La verdadera respuesta es evitar que esta excepción sea lanzada. Es un indicador de que algunos códigos se escribieron de manera deficiente y no se abordó el escenario en el que la referencia era null .

Si tiene un método al que se le llama donde necesita hacer algo con un argumento de tipo de referencia que debe ser anulado en algún punto, verifique si hay una null ArgumentNullException indique 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 configurable se puede establecer en null , verifique antes de InvalidOperationException y lance una InvalidOperationException indique el problema:

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

También debe asegurarse de que todos los métodos a los que llama que puedan devolver tipos de referencia tengan la garantía de devolver un valor. Para todos aquellos que no lo son, haga verificaciones similares de null y maneje el caso de manera apropiada.

EDITAR:

Para aclarar, no estoy sugiriendo que realice una comprobación de cada variable de tipo de referencia antes de desviarla. Eso sería una locura.

Se trata de comprender dónde puede asignarse una variable null y dónde no. 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 su clase se ha asegurado de que nunca pueda ser.

Un objeto bien diseñado restringirá las oportunidades para que se asignen valores null y utilizará el código de guarda donde sea apropiado para lanzar excepciones cuando un valor null pueda estar presente.