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 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 9 heures et 40 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 11 heures et 50 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