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 - 2 - Les différentes raisons

Cet article est composé de plusieurs parties :

 

Quelles sont donc ces raisons pour lesquelles la réponse est “non” ?

La première est en rapport direct avec “je” : ce n’est pas parce que l’exception n’est pas gérée dans notre code (celui dont nous sommes les auteurs) qu’elle ne le sera pas par le code (d’un tiers) que nous allons utiliser pour exécuter le notre.
Ce cas se présente avec l’utilisation du BackgroundWorker.

La seconde raison d’une absence de notification via l’évènement AppDomain.UnhandledException est qu’il existe, suivant le contexte d’exécution, d’autres moyens de notification similaires comme par exemple System.Windows.Forms.Application.ThreadException (WinForms) ou System.Windows.Application.DispatcherUnhandledException / System.Windows.Threading.Dispatcher.UnhandledException (WPF).
Ces éléments sont susceptibles de traiter certains problèmes en amont et donc d’empêcher la notification via AppDomain.UnhandledException.
(Je ne parle pas de l’évènement My.Application.UnhandledException disponible en VB.NET, qui à ma connaissance repose sur System.Windows.Forms.Application.ThreadException).

 

 

Le cas de l’utilisation de BackgroundWorker

Si nous utilisons le BackgroundWorker pour exécuter un code pouvant lever une exception non gérée, nous n’aurons pas de notification par un des évènements précédemment cités.
Ceci est tout simplement dû au fait qu’à l’exécution du code spécifié, le BackgroundWorker effectue une gestion d’exception afin de pouvoir la notifier via son évènement RunWorkerCompleted, plus précisément au travers de la propriété AsyncCompletedEventArgs.Error.
Si vous ne vous préoccupez pas de cette propriété, les exceptions non gérées du code passeront inaperçues.

 

Petit exemple d’utilisation de l’évènement RunWorkerCompleted en traitant les erreurs :

void worker_RunWorkerCompleted(Object sender, RunWorkerCompletedEventArgs e)
{
 
if (e.Cancelled)
 
{
   
// Si le traitement a été annulé
  }

 
else if (e.Error != null)
 
{
   
// Si une erreur (exception non gérée) est intervenue 
   
// durant le traitement 

   
Exception ex = e.Error;

   
// Nous traitons le cas où l'exception est de type 
   
// MyException
    if (ex is MyException)

   
{
     
// Traitement de l’erreur
   
}
   
else
   
{
     
// Nous ne savons pas gérer cette erreur 
      throw new BackgroundOperationFailedException(ex);

   
}
 
}
 
else
 
{
   
// Le traitement s'est terminé correctement
  }

}

 

La suite : 3 - Zoom sur Application.ThreadException (WinForms)

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

Commentaires

Pas de commentaires

Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- [ #SharePoint 2016 ] frappe à nos portes ! (1/2) par Le blog de Patrick [MVP Office 365] le 04-19-2015, 23:21

- Lync devient Skype Entreprise par Le petit blog de Pierre / Pierre's little blog le 04-18-2015, 22:47

- [WCF] Prendre la main sur les protocoles par Blog de Jérémy Jeanson le 04-18-2015, 12:57

- yOS Tour Geneva - Retour des sessions par Blog Technique de Romelard Fabrice le 04-16-2015, 11:54

- YOS Genève 2015 : gestion des gros fichiers et plus … par The Mit's Blog le 04-13-2015, 11:56

- YOS Genève 2015 : App et bonnes pratiques par The Mit's Blog le 04-13-2015, 10:55

- [YOS Genève 2015] : Et si on adoptait enfin nos espaces collaboratifs par The Mit's Blog le 04-13-2015, 09:48

- [WCF] Les bases d’une configuration clean par Blog de Jérémy Jeanson le 04-11-2015, 11:48

- Dernière partie de cache cache avec l’AppFabric le 2/04/2016 par Blog de Jérémy Jeanson le 04-08-2015, 23:01

- [WCF] Binding REST et SSL, c’est possible par Blog de Jérémy Jeanson le 04-04-2015, 09:19