Vea a continuación una explicación de lo que está sucediendo

Tengo un problema realmente extraño en el que la excepción detectada es nula.

El código usa MEF y se esfuerza por informar errores de composición. Usando el depurador puedo ver la excepción lanzada (unInvalidOperationException) pero cuando es atrapado por el último bloque de captura en el código debajo de laex variable es nula. Esto es cierto tanto en el depurador como cuando se ejecuta el código normalmente.

static T ResolveWithErrorHandling<T>() where T : class
{
    try
    {
        IocContainer.Compose(Settings.Default.IocConfiguration);
        return IocContainer.Resolve<T>();
    }
    catch (ReflectionTypeLoadException ex)
    {
        // ... special error reporting for ReflectionTypeLoadException
    }
    catch (Exception ex)
    {
        // ex is null - that should not be possible!
        // ... general error reporting for other exception types
    }
    return null;
}

El código que he reemplazado con comentarios es un código realmente simple para formatear el mensaje de error. No pasa nada extraño allí.

He intentado alterar el código para descubrir qué efecto podría tener:

Si elimino el primer bloque de captura ReflectionTypeLoadException) la excepción atrapada en el bloque de captura final ya no es nula. Si encuentro otro tipo de excepción en el primer bloque de captura, la excepción capturada en el bloque de captura final ya no es nula. Si agrego un bloque catch paraInvalidOperationException como primer bloque catch, la excepción atrapada en ese bloque no es nula. Si agrego un bloque catch paraInvalidOperationException entre los dos bloques catch la excepción atrapada en ese bloque es nula.

El proyecto usa Contratos de código y el código generado por el compilador se procesa posteriormente para verificar los contratos. Desafortunadamente, no he encontrado una manera de deshacerme de esto con fines de prueba sin realizar una cirugía mayor en el proyecto.

Mi solución actual es no atrapar aReflectionTypeLoadException y en su lugar se ramifica en el tipo deex en el controlador de excepciones generales.

¿Cuál podría ser la explicación de este comportamiento "imposible"? ¿Qué pasa conReflectionTypeLoadException bloque de captura?

amentablemente, la excepción no es nula y no puede ser nula según el estándar C # 15.9.5.

Sin embargo, utilizando los contratos de código en un proyecto puede estropear la visualización de variables locales en el depurador porque el código IL generado por el compilador puede ser reescrito por Code Contracts, por lo que el IL final no está sincronizado con la información de depuración. En mi caso laex variable se muestra como nulo aunque no lo sea. La desafortunada naturaleza de la notificación de errores que tuvo lugar justo antes de la finalización de la solicitud significaba que creía que la notificación de errores no se llamaba como resultado deex siendo nulo yex.Message tirando unNullReferenceException dentro de mi bloque de captura. Usando el depurador pude "verificar" queex era nulo, excepto que en realidad no era nulo.

Mi confusión se vio agravada por el hecho de que un bloqueo paraReflectionTypeLoadException parece afectar el problema de visualización del depurador.

Gracias a todos los que respondieron