Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

CoqBlog

.NET is good :-)
{ Blog de coq }

Actualités

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

Tableau décrivant les intéractions entre Application.ThreadException et 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.Forms.Application.ThreadException (WinForms) et AppDomain.UnhandledException

 

 

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) :

Les interactions entre System.Windows.Application.DispatcherUnhandledException / System.Windows.Threading.Dispatcher.UnhandledException (WPF) et AppDomain.UnhandledException

 

 

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 :
Posted: dimanche 26 octobre 2008 13:01 par coq
Classé sous : , ,

Commentaires

Lutinore a dit :

Nan mais ce mal de tête que j'ai après voir tenté de comprendre le 1er diagramme lol.

# janvier 22, 2009 21:54

coq a dit :

Je ne vois vraiment pas pourquoi :p

Je ne sais pas trop comment le rendre plus humain celui là :-(

# janvier 24, 2009 09:19
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- « Naviguer vers le haut » dans une librairie SharePoint par Blog de Jérémy Jeanson le 10-07-2014, 13:21

- PowerShell: Comment mixer NAGIOS et PowerShell pour le monitoring applicatif par Blog Technique de Romelard Fabrice le 10-07-2014, 11:43

- ReBUILD 2014 : les présentations par Le blog de Patrick [MVP Office 365] le 10-06-2014, 09:15

- II6 Management Compatibility présente dans Windows Server Technical Preview avec IIS8 par Blog de Jérémy Jeanson le 10-05-2014, 17:37

- Soft Restart sur Windows Server Technical Preview par Blog de Jérémy Jeanson le 10-03-2014, 19:43

- Non, le certificat public du CA n’est pas un certificat client !!! par Blog de Jérémy Jeanson le 10-03-2014, 00:08

- Windows Server Technical Preview disponible via MSDN par Blog de Jérémy Jeanson le 10-02-2014, 19:05

- Focus Sauvegardes SharePoint par Le blog de Patrick [MVP Office 365] le 10-02-2014, 13:11

- Technofolies, votre évènement numérique de l'année par Le Blog (Vert) d'Arnaud JUND le 09-26-2014, 18:40

- Xamarin : From Zero to Hero par Fathi Bellahcene le 09-24-2014, 17:35