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

- Evénement monfial Global Azure Bootcamp (10 000 participants) Venez !! par Blog de Vincent THAVONEKHAM, Objet Direct le il y a 8 heures et 34 minutes

- Mon Blog déplacé vers une version anglaise... www.thavo.com par Blog de Vincent THAVONEKHAM, Objet Direct le il y a 8 heures et 38 minutes

- Localisation et globalisation ne sont pas des options par Blog de Jérémy Jeanson le 01-17-2015, 11:47

- [Clean Code] les commentaires… par Fathi Bellahcene le 01-10-2015, 17:17

- Mise à jour de Test Professional 2013 par Blog de Jérémy Jeanson le 01-10-2015, 11:32

- [Dynamics CRM] Ajouter un bouton pour déclencher un workflow ou un script (dialogue) par Christine Dubois le 01-09-2015, 14:03

- RDV aux #SharePoint Days 2015 à Casablanca les 28 et 29 janvier ! par Le blog de Patrick [MVP Office 365] le 01-06-2015, 08:41

- TFS Online, vous allez aimer vos projets par Blog de Jérémy Jeanson le 01-03-2015, 11:19

- Bon code 2015 ! par Blog de Jérémy Jeanson le 01-02-2015, 19:01

- [Dynamics CRM] Créer un contact à partir d’une signature email par Christine Dubois le 12-30-2014, 14:37