A propos des notifications d’exceptions non gérées - 5 - Les interactions entre les différents évènements
Cet article est composé de plusieurs parties :
Les interactions entre System.Windows.Forms.Application.ThreadException (WinForms) et AppDomain.UnhandledException
Dans une application Windows Forms, si vous utilisez conjointement Application.ThreadException et AppDomain.UnhandledException (sur le même domaine d’application), UnhandledException ne sera en gros levé que pour les exceptions pour lesquelles ThreadException ne l’a pas été mais pas forcément pour toutes ces dernières : UnhandledException ne sera pas levé si jamais la boite de dialogue “Continuer/Quitter” citée en partie 3 - Zoom sur Application.ThreadException (WinForms) apparait.
En reprenant le tableau décrivant le comportement de Application.ThreadException :
TE = Application.ThreadException
UE = AppDomain.UnhandledException
Le diagramme ci-dessous devrait donner une vue plus claire de la chose (cliquez sur l’image pour l’avoir en taille réelle) :
Les interactions entre System.Windows.Application.DispatcherUnhandledException / System.Windows.Threading.Dispatcher.UnhandledException (WPF) et AppDomain.UnhandledException
Dans une application WPF, si vous utilisez conjointement Application.DispatcherUnhandledException/Dispatcher.UnhandledException et AppDomain.UnhandledException, la règle est à ma connaissance assez simple : si vous déclarez le problème comme étant géré dans le gestionnaire d’évènement Application.DispatcherUnhandledException/Dispatcher.UnhandledException, AppDomain.UnhandledException ne sera pas levé.
Dans le cas contraire il le sera (et l’application se terminera, sauf si la propriété UnhandledExceptionEventArgs.IsTerminating indique le contraire).
Le diagramme est cette fois-ci assez clair (cliquez sur l’image pour l’avoir en taille réelle) :
La suite : 6 - Notes diverses et conclusion
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
