mvc - unhandled exception c#

¿Cuál es la diferencia entre Application.ThreadException y AppDomain.CurrentDomain.UnhandledException?

Question

Bien, este es uno fácil:

• ¿Cuál es la diferencia entre Application.ThreadException y
  AppDomain.CurrentDomain.UnhandledException ?

• ¿Tengo que manejar ambos?

¡Gracias!

Answer 1

Application.ThreadException es específico de Windows Forms. Winforms ejecuta controladores de eventos en respuesta a los mensajes que le envía Windows. El evento Click, por ejemplo, estoy seguro de que los conoces. Si dicho controlador de eventos arroja una excepción, entonces hay un back-stop dentro del bucle de mensajes de Winforms que capta esa excepción.

Ese respaldo desactiva el evento Application.ThreadException . Si no lo anula, el usuario obtendrá un ThreadExceptionDialog . Lo que le permite ignorar la excepción y seguir ejecutando su programa. No es una gran idea por cierto.

Puede deshabilitar este comportamiento llamando a Application.SetUnhandledExceptionMode() en el método Main () en Program.cs. Sin ese respaldo en su lugar, lo normal sucede cuando un hilo muere por una excepción no controlada: AppDomain.UnhandledException dispara y el programa finaliza.

Fwiw: "ThreadException" fue una elección de nombre muy pobre. No tiene nada que ver con los hilos.

Answer 2

Bueno, la cosa es que ThreadException ocurre debido a un problema con su hilo, la excepción no controlada se ThreadException si el código arroja una excepción que no se maneja.

La forma más fácil de causar el segundo es crear una aplicación sin intentar ... atrapar bloques y lanzar una excepción.

Ahora bien, si necesita un seguro, puede manejar ambos, sin embargo, si captura y maneja sus exceptions correctamente, entonces no debería necesitar el controlador de UnhandledException no UnhandledException ya que es como atraparlo todo.

Answer 3

En las aplicaciones que usan formularios de Windows, las excepciones no controladas en el subproceso principal de la aplicación provocan que se Application.ThreadException evento Application.ThreadException . Si se maneja este evento, el comportamiento predeterminado es que la excepción no controlada no finaliza la aplicación, aunque la aplicación se deja en un estado desconocido. En ese caso, el evento UnhandledException no se genera. Este comportamiento se puede cambiar utilizando el archivo de configuración de la aplicación o utilizando el método Application.SetUnhandledExceptionMode para cambiar el modo a UnhandledExceptionMode.ThrowException antes de que el controlador de eventos ThreadException se ThreadException . Esto se aplica solo al hilo principal de la aplicación. El evento UnhandledException se genera para las excepciones no controladas lanzadas en otros hilos.

A partir de Visual Studio 2005 , el marco de aplicación de Visual Basic proporciona otro evento para las excepciones no controladas en el subproceso principal de la aplicación: WindowsFormsApplicationBase.UnhandledException . Este evento tiene un objeto de argumentos de evento con el mismo nombre que el objeto de argumentos de evento utilizado por AppDomain.UnhandledException, pero con diferentes propiedades. En particular, este objeto de argumentos de evento tiene una propiedad ExitApplication que permite que la aplicación continúe ejecutándose, ignorando la excepción no controlada (y dejando la aplicación en un estado desconocido). En ese caso, el evento AppDomain.UnhandledException no se genera.

Application.ThreadException se puede capturar y la aplicación podría continuar (en general no es una gran idea, pero para la aplicación, como ejecutar periódicamente algunas acciones, esta es una buena solución).

Para detectar las excepciones que ocurren en los subprocesos no creados y que son propiedad de los formularios de Windows, use AppDomain.UnhandledException . Permite a la aplicación registrar información sobre la excepción antes de que el controlador predeterminado del sistema informe la excepción al usuario y finalice la aplicación.
El manejo de esta excepción no impide que la aplicación finalice.
El máximo que se puede hacer (los datos del programa pueden dañarse cuando no se manejan las excepciones) está guardando los datos del programa para una recuperación posterior. Después de eso, el dominio de la aplicación se descarga y la aplicación finaliza.

A partir de .NET 4 , este evento no se genera para las excepciones que corrompen el estado del proceso, como desbordamientos de pila o violaciones de acceso, a menos que el controlador de eventos sea crítico para la seguridad y tenga el atributo HandleProcessCorruptedStateExceptionsAttribute .

Para obtener más detalles, consulte MSDN .

Answer 4

OK - Lo tenía delante de mí, este código del msdn es bastante autoexplicativo:

public static void Main(string[] args)
{
    // Add the event handler for handling UI thread exceptions to the event.
    Application.ThreadException += new 
        ThreadExceptionEventHandler(ErrorHandlerForm.Form1_UIThreadException);

    // Set the unhandled exception mode to force all Windows Forms 
    // errors to go through our handler.
    Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException);

    // Add the event handler for handling non-UI thread exceptions to the event. 
    AppDomain.CurrentDomain.UnhandledException +=
        new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);

    // Runs the application.
    Application.Run(new ErrorHandlerForm());
}