Muy bien, esto es fácil:¿Cuál es la diferencia entre Application.ThreadException y AppDomain.CurrentDomain.UnhandledException?
¿Cuál es la diferencia entre Application.ThreadException y AppDomain.CurrentDomain.UnhandledException?
¿Debo manejar ambos?
Gracias!
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 activa 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 al Application.SetUnhandledExceptionMode() en el método Main() en Program.cs. Sin esa protección en su lugar, lo normal sucede cuando un hilo muere por una excepción no controlada: AppDomain.UnhandledException incendios y el programa finaliza.
Fwiw: "ThreadException" era una opción de nombre muy pobre. No tiene nada que ver con los hilos.
Bueno, la cosa es que ThreadException se produce debido a un problema con el hilo, el Unhandled Exception se activa si el código arroja una excepción que no se maneja.
Manera fácil de causar la segunda es crear una aplicación sin intentar ... atrapar bloques y lanzar una excepción.
Ahora, si necesita un seguro, puede manejar ambos, sin embargo, si captura y maneja su exceptions correctamente, entonces no debería necesitar el controlador UnhandledException, ya que es una especie de trampa.
gracias - lo que no estaba demasiado claro era que si manejaba UnhandledException, también captaría ThreadException, que no parece ser el caso – JohnIdol
bien - lo tenía frente a mí, este trozo de código de msdn es bastante auto-explicativo:
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());
}
esto está en contraste con la otra respuesta de serhio cuando dice: UnhandledExceptionMode.ThrowException debe establecerse antes de que el controlador de eventos ThreadException esté conectado. No estoy seguro si la orden realmente importa ... –
@DavidePiras sí, y hay algo más turbio. SetUnhandledException parece no hacer diferencia en mi caso. – nawfal
En aplicaciones que utilizan Windows Forms, las excepciones no controladas en el hilo principal de la aplicación hacen que el evento Application.ThreadException a ser elevado. 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 mediante el método Application.SetUnhandledExceptionMode para cambiar el modo a UnhandledExceptionMode.ThrowException antes de conectar el controlador de eventos 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 subprocesos.
A partir de Visual Studio 2005, el Visual Basic marco de aplicación proporciona otro caso de excepciones no controladas en el hilo 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 pueden ser capturados y la aplicación podría continuar (en general, no es una gran idea, sino por la aplicación como correr periódicamente algunas acciones esta es una buena solución).
Para detectar excepciones que se producen en subprocesos no creados y propiedad de Windows Forms, 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 la .NET 4, este evento no se eleva para las excepciones que corrompen el estado del proceso, tales como desbordamientos de pila o violaciónes de acceso, a menos que el controlador de eventos es la seguridad crítica y tiene el atributo HandleProcessCorruptedStateExceptionsAttribute.
Para obtener más información, consulte MSDN.
Y cómo evitar que la aplicación WinForms falle en la aparición de 'Application.ThreadException'. Planteé una pregunta para este [[aquí] (http://stackoverflow.com/questions/23153287/suppressing-application-threadexception-and-appdomain-currentdomain-unhandledexc)] con mi pequeño código C#. – Mahesha999
Siempre lo leo como excepción de subproceso de aplicación, dado que winforms está vinculado a un solo subproceso. – Gusdor