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 - 6 - Notes diverses et conclusion

Cet article est composé de plusieurs parties :

 

Et pour les autres environnements ?

Pour les applications console et les services Windows, rien de particulier n’existe : toute la gestion éventuelle se fera via AppDomain.UnhandledException.

Pour les applications ASP.NET, ce n’est pas vraiment mon rayon.
Il existe un évènement pouvant permettre une gestion globale des exceptions : HttpApplication.Error. Par contre vous ne pouvez compter sur la levée de cet évènement dans tous les cas, on retrouve la même problématique que celle citée sur le BackgroundWorker en début d’article.
Par ailleurs je suppose que AppDomain.UnhandledException devrait quant à lui rester utilisable dans la théorie mais devrait à mon avis poser quelques problèmes à la mise en oeuvre : le mode de fonctionnement d’une application web ASP.NET comme celui de l’hôte qui l’héberge (recyclage de workerprocess sous IIS, etc) sont à prendre en compte.
Mais je suis loin de maitriser cette partie, je vous laisse donc à vos recherches.

 

 

Quelques notes à propos de la notion d’arrêt du processus

Il faut aussi savoir que la notion d’arrêt du processus hébergeant le CLR en cas d’exception non gérée est relative, ce n’est pas forcément le cas, particulièrement depuis .NET 2.0
Dans une application WinForms, Console, etc c’est le comportement observé car le CLR est le dernier gestionnaire pour une exception, et le choix par défaut est de mettre fin au processus.
Mais il est possible qu’un hôte choisisse de changer cette politique (via la méthode SetUnhandledExceptionPolicy définie par ICLRPolicyManager) : c’est le cas notamment avec SQL Server. Si votre code .NET hébergé échoue, vous n’entrainez bien évidemment pas l’instance complète dans votre chute.
Dans ce contexte de gestion finale par l’hôte je ne sais même pas si AppDomain.UnhandledException est levé, ni même si la propriété UnhandledExceptionEventArgs.IsTerminating fait état de la décision finale (ce qui en fin de compte ne pourrait être le cas que si l’évènement est levé après traitement de l’exception par l’hôte).
A confirmer avec quelqu’un maitrisant le hosting du CLR.

 

Enfin, un autre élément à garder à l’esprit, tout particulièrement en cas d’existant migré de .NET 1.x à .NET 2.0 et supérieurs : la présence éventuelle de l’élément “runtime/legacyUnhandledExceptionPolicy” dans le fichier de configuration de l’application.

En .NET 1.x, les exceptions non gérées dans un thread autre que le thread principal (background ou non), un thread de pool ou encore un thread de finalisation n’entrainaient pas l’arrêt du processus :
- Pour un thread de pool, l’exception était simplement notifiée sur la console et le thread retourné au pool comme si de rien n’était.
- Pour un thread standard (lancé via Thread.Start), l’exception était aussi notifiée sur la console et le thread était arrêté, toujours comme si de rien n’était.
- Pour un thread de finalisation, l’exception était notifiée sur la console et le thread continuait son exécution des finaliseurs suivants.

Avec .NET 2.0, ces comportements ont été modifiés : dorénavant toute exception non gérée sur ces éléments entraine l’arrêt du processus (du moins, cela doit tout de même être soumis à l’approbation de l’hôte).
Cependant l’élément “legacyUnhandledExceptionPolicy” permet de rétablir le comportement .NET 1.x, donc il faut y faire attention :

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
 
<runtime>
   
<legacyUnhandledExceptionPolicy enabled="1"/>
  </
runtime>
</configuration>

 

 

Utiliser AppDomain.UnhandledException, est ce toujours une bonne idée ?

Pour commencer, je dirais qu’il faut l’utiliser quand vous en avez réellement besoin.
L’utiliser sans but réel, juste pour l’utiliser, n’a pas forcément de sens.

De plus il faut toujours veiller à se placer dans le bon contexte : utiliser AppDomain.UnhandledException dans le contexte d’un développement pour SQL Server n’aura probablement pas beaucoup de sens.
S’attacher à l’évènement demande déjà de disposer de la permission ControlAppDomain (Security) qui à ma connaissance n’est disponible qu’en spécifiant un jeu de permissions UNSAFE au niveau de CREATE ASSEMBLY (que vous n’aurez sans doute jamais en production, et surtout pas si c’est “seulement” pour utiliser cet évènement).
De toute façon, en dehors de ces considérations, je doute qu’un hôte tel que SQL Server laisse un quelconque code utilisateur s’exécuter en cas d’exception non gérée.

Donc toujours bien faire attention au contexte d’exécution final de la solution : si vous êtes dans un contexte d’exécution avec un jeu de permissions du type FullTrust tout va bien, dans le cas contraire les ennuis peuvent commencer : exécutables lancés depuis un partage réseau (quoique ce problème est en partie réglé depuis .NET 3.5 SP1), hébergés dans un navigateur, hébergés par IIS, etc

 

Et voilà, c’est fini !

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

Commentaires

Pas de commentaires

Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- Compte rendu : SharePoint / O365 : des pratiques pour une meilleure productivité par The Mit's Blog le 12-12-2014, 18:11

- [TFS] Suppression des feature SQL Entreprise en masse par Blog de Jérémy Jeanson le 12-06-2014, 09:18

- [Clean Code] règles de nommage par Fathi Bellahcene le 12-04-2014, 22:59

- Windows To Go 10 et Upgrades impossibles par Blog de Jérémy Jeanson le 12-04-2014, 21:38

- SharePoint OnPremise: Statistiques d’utilisation pour traquer les sites fantomes par Blog Technique de Romelard Fabrice le 12-03-2014, 10:28

- SharePoint 2007: Script PowerShell permettant le backup de toutes les collections de sites d’une application Web par Blog Technique de Romelard Fabrice le 12-02-2014, 10:00

- Xamarin : un choix précieux par .net is good... C# is better ;) le 12-01-2014, 15:10

- Office 365: Comparaison des composants pour préparer votre migration de SharePoint 2007 vers Office 365 par Blog Technique de Romelard Fabrice le 11-28-2014, 16:20

- Créer un périphérique Windows To Go 10 ! par Blog de Jérémy Jeanson le 11-21-2014, 04:54

- RDV à Genève le 12 décembre pour l’évènement “SharePoint–Office 365 : des pratiques pour une meilleure productivité !” par Le blog de Patrick [MVP Office 365] le 11-19-2014, 10:40