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 - 4 - Zoom sur Application.DispatcherUnhandledException et Dispatcher.UnhandledException (WPF)

Cet article est composé de plusieurs parties :

 

Les évènements System.Windows.Application.DispatcherUnhandledException / System.Windows.Threading.Dispatcher.UnhandledException (WPF)

Les applications WPF disposent d’un équivalent de l’évènement Application.ThreadException des WinForms : il s’agit de Application.DispatcherUnhandledException, évènement d’instance cette fois, défini sur une classe Application (System.Windows.Application) qui n’a bien sûr rien à voir avec la classe Application (System.Windows.Forms.Application) que vous connaissez en WinForms.

Comme pour l’évènement WinForms, seules les exceptions levées sur des threads d’UI sont concernées, pas les autres.

Attention : Cet évènement ne sera levé que pour les exceptions intervenant dans le thread du Dispatcher principal (identifié par la propriété Application.Dispatcher) : s’abonner à Application.DispatcherUnhandledException depuis le thread sur lequel se trouve un autre Dispatcher permettra seulement au second Dispatcher d’être notifié des exceptions non gérées se produisant sur le premier.
Application.Current.DispatcherUnhandledException peut être plus ou moins grossièrement vu comme un raccourci vers Application.Current.Dispatcher.UnhandledException.
Pour les autres threads d’UI il faudra donc composer directement avec Dispatcher.UnhandledException (et Dispatcher.UnhandledExceptionFilter si nécessaire) : le fonctionnement est évidemment le même que celui de Application.DispatcherUnhandledException.

 

Exemple d’utilisation de Application.DispatcherUnhandledException :

App.xaml :
<Application x:Class="WpfApplication1.App"
    xmlns
="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

    xmlns:x
="http://schemas.microsoft.com/winfx/2006/xaml"

    StartupUri
="Window1.xaml"

    DispatcherUnhandledException
= "Application_DispatcherUnhandledException">

 
<Application.Resources>


 
</Application.Resources>

</Application>

App.xaml.cs :
/// <summary>
/// Interaction logic for App.xaml
/// </summary>
public partial class App : Application

{
 
private void Application_DispatcherUnhandledException(Object sender, DispatcherUnhandledExceptionEventArgs e)
 
{
   
// TODO : code de traitement de l'exception non gérée
  }

}

 

Une différence à noter par rapport à Application.ThreadException est que par défaut l’application se terminera sauf si nous déclarons explicitement avoir traité le problème. Exemple :

private void Application_DispatcherUnhandledException(Object sender, DispatcherUnhandledExceptionEventArgs e)
{
 
if (e.Exception is MyException)
 
{
   
// TODO : traitement

   
// Nous avons géré correctement le problème, 
   
// l'application peut continuer son exécution 
   
// de manière normale
    e.Handled = true;

 
}
}

 

Une autre différence à noter est le comportement en cas d’abonnements multiples à l’évènement : contrairement à Application.ThreadException, Application.DispatcherUnhandledException (tout comme AppDomain.UnhandledException) gère le mode multicast, donc si vous vous abonnez plusieurs fois, vous serez notifiés plusieurs fois.

En cas d’abonnements multiples, vous devez garder à l’esprit le fonctionnement de la propriété DispatcherUnhandledExceptionEventArgs.Handled abordée plus haut : une fois que vous aurez affectée la valeur true à cette propriété, vous ne pourrez plus la redéfinir à false. En clair : si un gestionnaire d’évènement déclare le problème géré, les suivants ne pourront rien y faire car une affectation de valeur false est purement et simplement ignorée.

 

La suite : 5 - Les interactions entre les différents évènements

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:00 par coq
Classé sous : , ,

Commentaires

Pas de commentaires

Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- 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

- Etes-vous yOS compatible ? (3/3) : la feuille de route par Le blog de Patrick [MVP SharePoint] le 06-06-2014, 00:30

- [MSDN] Utiliser l'approche Contract First avec Workflow Foundation 4.5 par Blog de Jérémy Jeanson le 06-05-2014, 21:19

- [ #ESPC14 ] TH10 Moving mountains with SharePoint ! par Le blog de Patrick [MVP SharePoint] le 06-01-2014, 11:30