name - remarks c#

La excepción inquebrantable, pt 2

Question

Actualización: he presentado un informe de error en Microsoft Connect: https://connect.microsoft.com/VisualStudio/feedback/details/568271/debugger-halting-on-exception-thrown-inside-methodinfo-invoke#details

Si puede reproducir este problema en su máquina, ¡anote el error para que se pueda solucionar!

Ok, he hecho algunas pruebas y he reducido el problema a algo muy simple:

yo. Crea un método en una nueva clase que lanza una excepción:

public class Class1 {
    public void CallMe() {
        string blah = null;
        blah.ToLower();
    }
}

ii. Cree un MethodInfo que apunte a este método en otro lugar:

Type class1 = typeof( Class1 );
Class1 obj = new Class1();
MethodInfo method = class1.GetMethod( "CallMe" );

iii. Envuelva una llamada a Invoke () en un bloque try / catch:

try {
    method.Invoke( obj, null ); // exception is not being caught!
} catch {
}

iv. Ejecute el programa sin el depurador (funciona bien).

v. Ahora ejecuta el programa con el depurador. El depurador detendrá el programa cuando se produzca la excepción, aunque esté envuelto en un controlador de captura que intenta ignorarlo. (¡Incluso si pones un punto de interrupción en el bloque de captura, se detendrá antes de que lo alcance!)

De hecho, la excepción ocurre cuando lo ejecuta sin el depurador también. En un proyecto de prueba simple se está ignorando en algún otro nivel, pero si su aplicación tiene algún tipo de manejo de excepciones globales, también se activará allí. [ver comentarios]

Esto me está causando un verdadero dolor de cabeza porque sigue provocando el controlador de bloqueos de mi aplicación, por no mencionar el dolor que supone intentar depurar.

Answer 1

No puedes atrapar todas las excepciones. Hay algunas suposiciones en tu ejemplo. Está, por ejemplo, suponiendo que la excepción se produjo en el subproceso de llamada. La captura de excepciones no controladas en otros subprocesos depende de los tiempos de ejecución que esté utilizando (consola, winforms, WPF, ASP.Net, etc.).

Además, las llamadas a System.Environment.FailFast () no generan ninguna condición manejable: el proceso se termina efectivamente sin posibilidad de intervención.

Answer 2

Puedo reproducir esto en mi cuadro .NET 4, y tienes razón, solo sucede en .NET 4.0.

Esto me huele mucho a un error y debería funcionar en MS Connect. Mayor problema si esto es disparar su controlador de accidente. Suena como una manera no placentera de solucionar esto, es envolver el método invocado dentro de su propio controlador. :-(

Una cosa que no puedo reproducir, sin embargo, es activar el controlador de fallos. Aquí está mi programa:

namespace trash {
    public class Class1 {
        public void CallMe() {
            string blah = null;
            blah.ToLower();
        }
    }

    class Program {
        static void Main(string[] args) {
            AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);           
            var class1 = typeof(Class1);
            var method = class1.GetMethod("CallMe");

            try {
                var obj = new Class1();
                method.Invoke(obj, null); // exception is not being caught!
            }
            catch (System.Reflection.TargetInvocationException) {
                Console.Write("what you would expect");
            }

        }

        static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e) {
            Console.Write("it would be horrible if this got tripped but it doesn''t!");
        }
    }
}