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

- [ #Yammer ] From Mailbox to Yammer and back / De votre messagerie vers Yammer et retour ! par Le blog de Patrick [MVP SharePoint] le 09-15-2014, 11:31

- [ #Office 365 ] New service settings panel / Nouveau panneau de paramétrage des services par Le blog de Patrick [MVP SharePoint] le 09-11-2014, 08:50

- Problème de déploiement pour une démo SharePoint/TFS? par Blog de Jérémy Jeanson le 09-10-2014, 21:52

- [ #Office365 ] Delve first impressions / Premières impressions sur Delve par Le blog de Patrick [MVP SharePoint] le 09-09-2014, 16:57

- [ #Office365 ] How to change Administration console language ? / Comment changer la langue de la console d’administration ? par Le blog de Patrick [MVP SharePoint] le 09-09-2014, 08:25

- [ #SharePoint 2013 ] Suppression de bases de données en état “Pas de Réponse” par Le blog de Patrick [MVP SharePoint] le 09-04-2014, 14:10

- Changer l’adresse d’une ferme Office Web Apps associée à SharePoint par Blog de Jérémy Jeanson le 09-01-2014, 22:21

- Une ferme #SharePoint 2013 dans @Azure en quelques clics (1ère partie) ! par Le blog de Patrick [MVP SharePoint] le 08-28-2014, 18:52

- SharePoint 2013: Préparation de la migration - Création des site Templates dans 2010 et 2013 par Blog Technique de Romelard Fabrice le 08-20-2014, 16:31

- [ #Yammer ] How to change interface language ? Comment changer la langue de l’interface ? par Le blog de Patrick [MVP SharePoint] le 08-20-2014, 14:21