Quelle est la différence entre L'Application.ThreadException et AppDomain.CurrentDomain.UnhandledException?

Dans les applications qui utilisent Windows Forms, les exceptions non gérées dans le thread principal de l'application Application.ThreadException événement à soulever. Si cet événement est géré, le comportement par défaut est que l'exception non gérée ne met pas fin à l'application, bien que l'application reste dans un état inconnu. Dans ce cas, l'événement UnhandledException n'est pas déclenché. Ce comportement peut être modifié à l'aide du fichier de configuration de l'application ou à l'aide de la méthode Application.SetUnhandledExceptionMode pour changer le mode en UnhandledExceptionMode.ThrowException avant que le gestionnaire d'événements ThreadException ne soit connecté. Ceci s'applique uniquement au thread d'application principal. L'événement UnhandledException est déclenché pour les exceptions non gérées lancées dans d'autres threads.

À partir de Visual Studio 2005 , le cadre d'application Visual Basic fournit un autre événement pour les exceptions non gérées dans le thread d'application principal - WindowsFormsApplicationBase.UnhandledException. Cet événement a un objet arguments d'événement avec le même nom que l'objet arguments d'événement utilisé par AppDomain.UnhandledException, mais avec des propriétés différentes. En particulier, cet objet Event arguments possède une propriété ExitApplication qui permet à l'application de continuer à s'exécuter, en ignorant l'exception non gérée (et en laissant l'application dans un état inconnu). Dans ce cas, le domaine d'application.L'événement UnhandledException n'est pas déclenché.

Application.ThreadException peut être interceptée et le application pourrait continuer (en général n'est pas une bonne idée, mais pour l'application, comme la course périodiquement certaines actions, c'est un bon solution).

Pour détecter les exceptions qui se produisent dans les threads Non créés et appartenant à Windows Forms, utilisez AppDomain.UnhandledException. Il permet à l'application de consigner des informations sur l'exception avant que le gestionnaire par défaut du système ne signale l'exception à l'utilisateur et ne termine l'application.
la gestion de cette exception n'empêche pas la fin de l'application.
le maximum qui pourrait être fait(les données du programme peuvent être corrompues lorsque les exceptions ne sont pas gérées) enregistre les données du programme pour une récupération ultérieure. Après que le domaine d'application est déchargé et l'application se termine.

En commençant par . net 4, cet événement n'est pas déclenché pour les exceptions qui corrompent l'état du processus, telles que les débordements de pile ou les violations d'accès, sauf si le gestionnaire d'événements est critique pour la sécurité et possède l'attribut HandleProcessCorruptedStateExceptionsAttribute.

Pour plus de détails, voir MSDN.

OK-je l'avais devant moi, ce bit de code de msdn est assez explicite:

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());
}

Eh bien, la chose est, ThreadException se produit en raison d'un problème avec votre thread, le Unhandled Exception est déclenché si vous codez une exception qui n'est pas gérée.

Plus faciles à causer la seconde est de créer une application sans essayer...attrapez les blocs et lancez une exception.

Maintenant, si vous avez besoin d'assurance, vous pouvez les gérer tous les deux, mais si vous capturez et gérez votre exceptions correctement, vous ne devriez pas avoir besoin du gestionnaire UnhandledException car c'est un peu comme un catch all.