¿Cómo puede la excepción atrapada ser nula (no NullReferenceException)?

Me he encontrado con un pequeño problema bastante raro.¿Cómo puede la excepción atrapada ser nula (no NullReferenceException)?

En el siguiente código no puedo entender cómo e puede ser e puede ser ;

try 
{ 
    //Some Code here 
} 
catch (Exception e) 
{ 
    //Here e is null 
}

Por lo que yo sé, throw null se convertirá en throw new NullReferenceException().

El problema parece estar relacionado con el multihilo, ya que la eliminación de otro hilo también parece solucionarlo. O al menos solo lo he visto cuando el código anterior se ejecuta en un nuevo hilo. El programa completo usa muchos hilos y es un poco complejo.

De todos modos mi pregunta es, ¿cómo puede e ser nulo? - Afortunadamente, la respuesta a eso puede ayudar a encontrar la fuente de este problema.

Editar lo descubrí, ya que causó una NullReferenceException en la declaración de capturas, y utilizando el depurador veo la misma cosa.

Editar 2 abierto VisualStudio al día siguiente lo intentó de nuevo, no hay cambios en el código y ahora el mismo eslogan es "llamado", pero esta vez de correo no es nulo. Parece que fue un error de VS.

Fuente

2009-12-03 Jacob Poul Richardt

Parece que ya has puesto el dedo en el problema. Necesitas enderezar la pisada. –

¿Cómo determinas que e es de hecho nulo? Probé algunos ejemplos y leí las especificaciones de CLI en excepciones y no parece permitir que un valor de excepción sea nulo. Además, si fuera nulo, no tendría un tipo y, por lo tanto, no podría cumplir los criterios de filtro por ser de tipo excepción.

¿Está utilizando el depurador para verificar este valor? Si es así, intente cambiarlo a una afirmación en línea.

Fuente

2009-12-03 17:35:10 JaredPar

Actualizaré la pregunta con esto. Pero me llamó la atención porque una NullReferenceException fue lanzada desde la declaración catch. Y usando el depurador veo lo mismo. –

@Lillemanden, esto no prueba que sea nulo. Solo un Debug.Assert (e! = Null, "Definitivamente es nulo") o un cheque similar lo hará. – JaredPar

El depurador a veces miente. Recuerdo que hay algo entretenido con las constantes y el depurador donde parecen estar vacíos o nulos cuando no están en la realidad. – Quibblesome

Es posible que la excepción lanzada no sea compatible con CLS, lo que realmente no debería ser atrapado por un Try/Catch con un filtro.

Sólo debe ser capaz de coger un CLS Cumple con un try {} catch {} sin excepción "argumento"

Fuente

2009-12-03 18:07:07

Estoy bastante seguro de que todo el código cumple con CLS. Aunque no es 100% Pero nunca he tenido este problema antes. Y hay muchas otras declaraciones de captura, la mayoría de las cuales deberían haber sido probadas por pruebas unitarias. –

¿Estás positivo que estabas fuera de la línea de excepciones e?

try 
{ 
    //Some Code here 
} 
catch (Exception e) 
{ 
    int i = 0; // breakpoint here 
}

Sólo pido esto porque yo nunca, nunca he visto este tipo de comportamiento y sé que si punto de interrupción de excepción e, e parece ser nula. En la siguiente línea, no es nulo.

Fuente

2009-12-03 18:09:17 Quibblesome

Sí, estoy seguro. El uso de e dentro de la declaración de catch provocó una NullReferenceException allí. –

Tengo la misma situación, también. Resultó ser un error del depurador de Eclipse. El reinicio de Eclipse es suficiente: la excepción de tiempo de ejecución se vuelve normal, no nula.

Fuente

2012-01-18 09:23:03 Gangnus

¿Cómo puede la excepción atrapada ser nula (no NullReferenceException)?

Respuesta

Cuestiones relacionadas