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

- SharePoint 2013: Préparation de la migration - Création des site Templates dans 2010 et 2013 par Blog Technique de Romelard Fabrice le il y a 13 heures et 38 minutes

- [ #Yammer ] How to change interface language ? Comment changer la langue de l’interface ? par Le blog de Patrick [MVP SharePoint] le il y a 15 heures et 48 minutes

- Onedrive Sync Engine Host : CPU à 100% par Le petit blog de Pierre / Pierre's little blog le 08-06-2014, 22:22

- SharePoint : Bug sur la gestion des permissions et la synchronisation Office par Blog Technique de Romelard Fabrice le 07-10-2014, 11:35

- SharePoint 2007 : La gestion des permissions pour les Workflows par Blog Technique de Romelard Fabrice le 07-08-2014, 11:27

- TypeMock: mock everything! par Fathi Bellahcene le 07-07-2014, 17:06

- Coding is like Read par Aurélien GALTIER le 07-01-2014, 15:30

- Mes vidéos autour des nouveautés VS 2013 par Fathi Bellahcene le 06-30-2014, 20:52

- Recherche un passionné .NET par Tkfé le 06-16-2014, 12:22

- [CodePlex] Projet KISS Workflow Foundation lancé par Blog de Jérémy Jeanson le 06-08-2014, 22:25