Gestionnaire d'exceptions non géré dans .NET 1.1

StackOverflow https://stackoverflow.com/questions/944

Question

Je gère une application .NET 1.1 et l'une des tâches qui m'ont été confiées est de m'assurer que l'utilisateur ne voit aucune notification d'erreur hostile.

J'ai ajouté des gestionnaires à Application.ThreadException et AppDomain.CurrentDomain.UnhandledException, qui sont appelés.Mon problème est que la boîte de dialogue d'erreur CLR standard est toujours affichée (avant l'appel du gestionnaire d'exceptions).

Jeff parle de ce problème sur son blog ici et ici.Mais il n'y a pas de solution.Alors, quelle est la méthode standard dans .NET 1.1 pour gérer les exceptions non interceptées et afficher une boîte de dialogue conviviale ?

La réponse de Jeff a été marquée comme étant la bonne réponse, car le lien qu'il a fourni contient les informations les plus complètes sur la façon de faire ce qui est requis.

Était-ce utile?

La solution

Oh, dans Windows Forms, vous devriez certainement pouvoir le faire fonctionner.La seule chose à laquelle vous devez faire attention, ce sont les choses qui se passent sur différents fils de discussion.

J'ai ici un ancien article de Code Project qui devrait aider :

Gestion conviviale des exceptions

Autres conseils

AppDomain.UnhandledException est un événement, pas un gestionnaire d'exceptions global.Cela signifie qu'au moment où elle est déclenchée, votre application est déjà en train de disparaître et vous ne pouvez rien y faire, à part effectuer un nettoyage et une journalisation des erreurs.

Voici ce qui s'est passé dans les coulisses :Le framework a détecté l'exception, a remonté la pile d'appels jusqu'au sommet, n'a trouvé aucun gestionnaire capable de récupérer de l'erreur et n'a donc pas pu déterminer s'il était sûr de poursuivre l'exécution.Ainsi, il a commencé la séquence d'arrêt et a déclenché cet événement par courtoisie envers vous afin que vous puissiez rendre hommage à votre processus déjà voué à l'échec.Cela se produit lorsqu'une exception n'est pas gérée dans le thread principal.

Il n’existe pas de solution unique à ce type d’erreur.Vous devez placer un véritable gestionnaire d'exceptions (un bloc catch) en amont de tous les endroits où cette erreur se produit et le transmettre (par exemple) à une méthode/classe de gestionnaire global qui déterminera s'il est sûr de simplement signaler et continuer, en fonction de type et/ou contenu de l’exception.

Modifier:Il est possible de désactiver (= pirater) le mécanisme de rapport d'erreurs intégré à Windows afin que la boîte de dialogue obligatoire "planter et graver" ne s'affiche pas lorsque votre application tombe en panne.Toutefois, cela devient efficace pour tous les applications du système, pas seulement les vôtres.

Le comportement des exceptions non gérées dans une application Windows Forms .NET 1.x dépend de :

  • Le type de thread qui a levé l'exception
  • Si cela s'est produit pendant le traitement des messages de fenêtre
  • Si un débogueur était attaché au processus
  • Le paramètre de registre DbgJitDebugLaunchSetting
  • L'indicateur jitDebugging dans App.Config
  • Si vous avez remplacé le gestionnaire d'exceptions Windows Forms
  • Si vous avez géré l'événement d'exception du CLR
  • La phase de la lune

Le comportement par défaut des exceptions non gérées est :

  • Si l'exception se produit sur le thread principal lors du pompage des messages de la fenêtre, elle est interceptée par le gestionnaire d'exceptions Windows Forms.
  • Si l'exception se produit sur le thread principal lors du pompage des messages de la fenêtre, elle mettra fin au processus d'application à moins qu'elle ne soit interceptée par le gestionnaire d'exceptions Windows Forms.
  • Si l’exception se produit sur un thread manuel, un pool de threads ou un finaliseur, elle est avalée par le CLR.

Les points de contact pour une exception non gérée sont :

  • Gestionnaire d’exceptions Windows Forms.
  • Le commutateur de registre de débogage JIT DbgJitDebugLaunchSetting.
  • L'événement d'exception non géré par le CLR.

La gestion des exceptions intégrée au Windows Form effectue les opérations suivantes par défaut :

  • Intercepte une exception non gérée lorsque :
    • l'exception concerne le thread principal et aucun débogueur n'est connecté.
    • une exception se produit lors du traitement des messages de fenêtre.
    • jitDebugging = false dans App.Config.
  • Affiche la boîte de dialogue à l'utilisateur et empêche la fermeture de l'application.

Vous pouvez désactiver ce dernier comportement en définissant jitDebugging = true dans App.Config.Mais rappelez-vous que cela peut être votre dernière chance d'arrêter la fermeture de l'application.Ainsi, la prochaine étape pour intercepter une exception non gérée consiste à s'inscrire à l'événement Application.ThreadException, par exemple :

Application.ThreadException += new
Threading.ThreadExceptionHandler(CatchFormsExceptions);

Notez le paramètre de registre DbgJitDebugLaunchSetting sous HKEY_LOCAL_MACHINE\Software.NetFramework.Cela a l'une des trois valeurs dont je suis conscient :

  • 0 :affiche une boîte de dialogue utilisateur demandant « déboguer ou terminer ».
  • 1:laisse passer l'exception pour que CLR puisse la gérer.
  • 2 :lance le débogueur spécifié dans la clé de registre DbgManagedDebugger.

Dans Visual Studio, accédez au menu Outils → Possibilités → Débogage → JIT pour définir cette clé sur 0 ou 2.Mais une valeur de 1 est généralement la meilleure sur la machine d'un utilisateur final.Notez que cette clé de registre est utilisée avant l’événement d’exception non géré CLR.

Ce dernier événement est votre dernière chance de consigner une exception non gérée.Il est déclenché avant l'exécution de vos blocs Enfin.Vous pouvez intercepter cet événement comme suit :

AppDomain.CurrentDomain.UnhandledException += new
System.UnhandledExceptionEventHandler(CatchClrExceptions);

S'agit-il d'une application console ou d'une application Windows Forms ?S'il s'agit d'une application console .NET 1.1, c'est malheureusement dû à sa conception - cela est confirmé par un développeur MSFT dans le deuxième article de blog auquel vous avez fait référence:

BTW, sur ma machine 1.1, l'exemple de MSDN a le résultat attendu ;c'est juste que la deuxième ligne n'apparaît qu'après avoir attaché un débogueur (ou non).Dans la version 2, nous avons inversé les choses afin que l'événement UnhandledException se déclenche avant que le débogueur ne se connecte, ce qui semble être ce à quoi la plupart des gens s'attendent.

Il semble que .NET 2.0 fasse mieux (Dieu merci), mais honnêtement, je n'ai jamais eu le temps de revenir en arrière et de vérifier.

C'est une application Windows Forms.Les exceptions interceptées par Application.ThreadException fonctionnent correctement et je ne reçois pas la vilaine boîte d'exception .NET (D'ACCORD Terminer, Annuler déboguer ?qui a inventé ça ??).

J'obtenais des exceptions qui n'étaient pas détectées et j'ai fini par accéder à l'événement AppDomain.UnhandledException qui posait des problèmes.Je pense avoir détecté la plupart de ces exceptions et je les affiche maintenant dans notre jolie boîte d'erreur.

Je dois donc simplement espérer qu'il n'y a pas d'autres circonstances qui empêcheraient les exceptions d'être interceptées par le gestionnaire Application.ThreadException.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top