À l'échelle mondiale intercepter des exceptions dans une application WPF?

Nous sommes d'avoir une application WPF zones où il peut lancer des exceptions à l'exécution. J'aimerais à l'échelle mondiale attraper une exception non gérée et journal, mais en tout cas de poursuivre l'exécution du programme comme si de rien n'était (un peu comme VB est On Error Resume Next).

Est-ce possible en C#? Et si oui, où exactement, ai-je besoin de mettre le code de gestion des exceptions?

Actuellement je ne vois pas un seul point où je pouvais emballer un try/catch autour et qui permettrait d'intercepter toutes les exceptions qui pourraient se produire. Et même alors je l'ai laissé tout ce qui a été exécuté en raison de la capture. Ou suis-je en pensant à mal les directions ici?

ETA: Parce que beaucoup de gens au-dessous de l'a signalé: L'application n'est pas pour le contrôle des centrales nucléaires. Si il plante, il n'est pas beaucoup d'une grosse affaire, mais au hasard des exceptions qui sont pour la plupart liées à l'INTERFACE utilisateur sont une nuisance dans le contexte où il sera utilisé. Il y avait (et probablement encore) un peu de ceux-ci et depuis il utilise une architecture de plugin et peut être prolongé par d'autres (également les étudiants dans ce cas; de sorte pas développeurs expérimentés qui sont capables d'écrire complètement exempt d'erreurs de code).

Comme pour les exceptions coincés: je ne les enregistre dans un fichier journal, y compris la trace de la pile complète. Qui a été le point de l'ensemble de l'exercice. Juste pour contrer ces gens qui ont été en prenant mon analogie à VB de OERN trop littéralement.

Je sais que l'aveuglette en ignorant certaines classes d'erreurs est dangereux et peut corrompre mon instance de l'application. Comme dit précédemment, ce programme n'est pas critique pour n'importe qui. Personne dans leur bon esprit pari de la survie de la civilisation humaine sur elle. C'est tout simplement un petit outil qui permet de tester certaines des approches de conception wrt. génie logiciel.

Pour l'utilisation immédiate de l'application il n'y a pas beaucoup de choses qui peuvent se produire sur une exception:

Pas de la gestion des exceptions – dialogue d'erreur et la fermeture de l'application. L'expérience doit être répétée, bien que probablement avec un autre sujet. Aucune erreur n'a été enregistré, ce qui est regrettable.
Générique de gestion des exceptions – bénigne erreur interceptée, pas de dégâts. Ce devrait être le cas le plus courant jugé à partir de toutes les erreurs, nous avons pu assister au cours du développement. Le fait d'ignorer ce genre d'erreurs devraient pas avoir de conséquences immédiates; les structures de données de base sont bien testé assez facilement survivre à ça.
Générique de gestion des exceptions – grave erreur interceptée, éventuellement bloquer à un moment plus tard. Cela peut se produire rarement. Nous n'avons jamais vu ça jusqu'à présent. L'erreur est quand même enregistré et un accident est peut-être inévitable. Donc, c'est conceptuellement similaire à la première affaire. Sauf que nous avons une trace de la pile. Et dans la majorité des cas, l'utilisateur ne remarquerez même pas.

Comme pour l'expérience des données générées par le programme: Une grave erreur, au pire, juste cause, aucune donnée ne sera enregistrée. De subtils changements qui modifient le résultat de cette expérience un tant soit peu sont assez improbable. Et même dans ce cas, si les résultats semblent douteux, l'erreur a été enregistrée; on peut encore jeter ce point de données si c'est un total de valeurs aberrantes.

Pour résumer: Oui, je me considère toujours, au moins partiellement, sain d'esprit et je ne considère pas une exception mondial d'une routine de gestion qui quitte le programme en cours d'exécution à être nécessairement totalement mal. Comme l'a dit deux fois auparavant, une telle décision peut être valide, en fonction de l'application. Dans ce cas, il a été jugé valide décision et de ne pas totale et absolue de la connerie. Pour toute autre demande que la décision soit différent. Mais merci de ne pas m'accuser ou de l'autre des gens qui ont travaillé sur ce projet pour potentiellement faire sauter le monde, juste parce que nous sommes en ignorant les erreurs.

Note de côté: Il y a exactement un utilisateur pour cette application. Ce n'est pas quelque chose comme Windows ou Office qui est utilisé par des millions de personnes, où le coût d'avoir des exceptions bulle à l'utilisateur serait très différente, en premier lieu, déjà.

Ce pas vraiment la pensée--oui, vous voulez probablement l'application pour quitter. MAIS, ne serait-il pas agréable à la première ouverture de session de l'exception avec ses StackTrace? Si tout que vous avez obtenu de l'utilisateur a été, "Votre demande est tombé en panne lorsque j'ai appuyé sur ce bouton, vous pouvez ne jamais être en mesure de résoudre le problème, parce que vous n'aurez pas suffisamment d'informations. Mais si vous avez d'abord enregistré l'exception avant plus agréablement l'abandon de l'application, vous aurez beaucoup plus d'informations.
J'ai élaboré ce point un peu dans la question maintenant. Je connais les risques encourus, et pour une application particulière, il a été jugé acceptable. Et l'abandon de la demande pour quelque chose d'aussi simple qu'un indice hors limites, tandis que l'INTERFACE utilisateur a essayé de faire quelques belles animation est excessif et inutile. Oui, je ne sais pas la cause exacte, mais nous avons des données pour sauvegarder la réclamation que la grande majorité des cas d'erreur est bénigne. Les plus graves, nous sommes de masquage peut provoquer un dysfonctionnement de l'application, mais c'est ce qui se serait passé sans mondial de gestion de l'exception de toute façon.
D'un autre côté remarque: si vous voulez éviter les accidents avec cette approche, les utilisateurs n'auront plus de chances d'amour il.
Voir Windows Manipulation des Exceptions Non gérées dans WPF (collection La plus complète de gestionnaires) de l'échantillon en C# sur Visual Studio 2010. Il a 5 exemples, y compris le domaine d'application.CurrentDomain.FirstChanceException, Application.DispatcherUnhandledException et domaine d'application.CurrentDomain.UnhandledException.

InformationsquelleAutor Joey | 2009-04-27

c#exception exception-handling wpf

171

Utiliser le Application.DispatcherUnhandledException Événement. Voir cette question un résumé (voir Drew Noakes réponse).

Être conscient qu'il y aura toujours des exceptions, qui s'opposent à une réussite de la reprise de votre application, comme après un débordement de pile, épuisé de mémoire, ou de la perte de la connectivité réseau pendant que vous êtes en essayant de sauver de la base de données.
- Merci. Et oui, je suis conscient qu'il y a des exceptions à partir de laquelle je ne peux pas le récupérer, mais la grande majorité de ceux qui pourraient se produire sont bénignes dans ce cas.
- Si votre exception se produit sur un thread d'arrière-plan (par exemple, à l'aide de pool de threads.QueueUserWorkItem), cela ne fonctionnera pas.
- bon point, mais ceux qui peuvent être traitées avec un bloc try autour de la workitem, non?
- Mais, comment pouvons-nous reprendre à partir de l'aide de l'gestionnaires?
- Le gestionnaire est appelé comme l'événement principal de la boucle. Lorsque les gestionnaires d'événement renvoie, votre application se poursuit normalement.
- Il semble que nous devons nous fixer des e.Manipulés = true, où e est un DispatcherUnhandledExceptionEventargs, pour sauter le gestionnaire par défaut qui quittez les programmes. msdn.microsoft.com/en-us/library/...
- La réponse doit être modifié pour tenir compte de l'e.Manipulés =true
- Cette solution pourrait ne pas être suffisante pour intercepter toutes les exceptions. Il est très probable que les threads d'arrière-plan peut échouer dans une assez mauvaise façon de planter votre application, je recommande également la mise en œuvre de @charithj solution avec le domaine d'application.UnhandledException ou à l'aide de LegacyUnhandledExceptionPolicy...
- vous ne pouvez pas marquer comme traité il y bien que.
- Merci @Konrad qui est probablement vrai, mais pouvez-vous pas simplement ignorer l'exception, dans mon expérience, sauf si c'est une mémoire chercher violation, ou impliquant COM+ ou Api Win32, puis la loi de la capture de l'exception est normalement suffisant pour permettre le principal thread d'INTERFACE utilisateur pour continuer. Au moins par la capture de l'exception, vous pouvez vous connecter ou de les analyser, trouver la cause racine est et de remédier à ce problème, ou de façon plus agressive intercepter l'exception plus près de la source, permettant à votre application pour continuer dans l'avenir. Pensez-y comme un "oups" genre de fail-safe, une fois que vous avez l'exception, alors vous saurez quoi faire.
- c'est vrai, j'ai seulement à l'échelle mondiale poignée HTTP exceptions (problème de connexion, etc.) pour éviter de passe-partout dans mon code.
InformationsquelleAutor David Schmitt

Un exemple de code utilisant NLog qui va attraper les exceptions levées de tous les threads dans le domaine d'application, à partir de la de l'INTERFACE utilisateur répartiteur fil et de la async fonctions:

App.xaml.cs :

public partial class App : Application
{
    private static Logger _logger = LogManager.GetCurrentClassLogger();

    protected override void OnStartup(StartupEventArgs e)
    {
        base.OnStartup(e);

        SetupExceptionHandling();
    }

    private void SetupExceptionHandling()
    {
        AppDomain.CurrentDomain.UnhandledException += (s, e) =>
            LogUnhandledException((Exception)e.ExceptionObject, "AppDomain.CurrentDomain.UnhandledException");

        DispatcherUnhandledException += (s, e) =>
            LogUnhandledException(e.Exception, "Application.Current.DispatcherUnhandledException");

        TaskScheduler.UnobservedTaskException += (s, e) =>
            LogUnhandledException(e.Exception, "TaskScheduler.UnobservedTaskException");
    }

    private void LogUnhandledException(Exception exception, string source)
    {
        string message = $"Unhandled exception ({source})";
        try
        {
            System.Reflection.AssemblyName assemblyName = System.Reflection.Assembly.GetExecutingAssembly().GetName();
            message = string.Format("Unhandled exception in {0} v{1}", assemblyName.Name, assemblyName.Version);
        }
        catch (Exception ex)
        {
            _logger.Error(ex, "Exception in LogUnhandledException");
        }
        finally
        {
            _logger.Error(exception, message);
        }
    }

C'est le plus complet de réponse ici! Cherche un job scheduler exceptions sont inclus. Le mieux pour moi, simple et propre code.
Récemment, j'ai eu une Application.config de la corruption à un client, et son Application n'était même pas encore commencer car NLog a été d'essayer de lire à partir de l'App.config et a déclenché une exception. Depuis cette exception est dans la statique de l'enregistreur de initialiseur, il n'était pas d'être pris par la UnhandledException gestionnaire. J'ai dû le regarder Journal des Événements Windows Viewer pour trouver ce qui se passait...
Vous ne pouvez pas marquer comme traité si.

InformationsquelleAutor Hüseyin Yağlı

28

Domaine d'application.UnhandledException Événement

Cet événement fournit une notification de ce type d'exception. Il permet à l'
application pour enregistrer des informations sur l'exception avant le système
le gestionnaire par défaut des rapports de l'exception à l'utilisateur et met fin à la
application.
```
   public App()
   {
      AppDomain currentDomain = AppDomain.CurrentDomain;
      currentDomain.UnhandledException += new UnhandledExceptionEventHandler(MyHandler);    
   }

   static void MyHandler(object sender, UnhandledExceptionEventArgs args) 
   {
      Exception e = (Exception) args.ExceptionObject;
      Console.WriteLine("MyHandler caught : " + e.Message);
      Console.WriteLine("Runtime terminating: {0}", args.IsTerminating);
   }
```
Si le UnhandledException événement est géré dans l'application par défaut
domaine, il est élevé pour une exception non gérée dans n'importe quel thread,
n'importe quel domaine d'application le thread lancé. Si le thread
commencé dans un domaine d'application qui a un gestionnaire d'événements pour
UnhandledException, l'événement est déclenché dans ce domaine d'application. Si
ce domaine d'application n'est pas la valeur par défaut domaine d'application, et
il y a aussi un gestionnaire d'événement dans le domaine d'application par défaut, l'
l'événement est déclenché dans les deux domaines d'application.

Par exemple, supposons qu'un thread démarre dans le domaine d'application "AD1",
appelle une méthode dans le domaine d'application "AD2", et à partir de là, les appels d'un
méthode dans le domaine d'application "après jc3", où il déclenche une exception. L'
premier domaine d'application dans lequel le UnhandledException événement peut être
soulevée est "AD1". Si ce domaine d'application n'est pas la valeur par défaut
domaine d'application, l'événement peut également être soulevées par défaut
domaine d'application.
- vous ne savez pas si vous pouvez avoir votre propre Main() sur WPF
- la copie à partir de l'URL que vous avez souligné (qui parle de console apps et les applications WinForms seulement je crois): "à Partir avec la .NET Framework 4, cet événement n'est pas déclenché pour les exceptions que la corruption de l'état du processus, tels que les débordements de pile ou de violations d'accès, à moins que le gestionnaire d'événements est critique de sécurité et a la HandleProcessCorruptedStateExceptionsattribute attribut."
- Vous pouvez vous abonner pour UnhandledException événement dans l'Application du constructeur.
- pense que c'est plus clair maintenant, après la modifier
InformationsquelleAutor CharithJ
17

En plus de ce que les autres mentionnés ici, notez que la combinaison de la Application.DispatcherUnhandledException (et ses similaires) avec
```
<configuration>
  <runtime>  
    <legacyUnhandledExceptionPolicy enabled="1" />
  </runtime>
</configuration>
```
dans le app.config empêchera votre threads secondaires exception de l'arrêt de l'application.

InformationsquelleAutor Hertzel Guinness

Ici est un parfait exemple à l'aide de NLog

using NLog;
using System;
using System.Windows;

namespace MyApp
{
    ///<summary>
    ///Interaction logic for App.xaml
    ///</summary>
    public partial class App : Application
    {
        private static Logger logger = LogManager.GetCurrentClassLogger();

        public App()
        {
            var currentDomain = AppDomain.CurrentDomain;
            currentDomain.UnhandledException += CurrentDomain_UnhandledException;
        }

        private void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
        {
            var ex = (Exception)e.ExceptionObject;
            logger.Error("UnhandledException caught : " + ex.Message);
            logger.Error("UnhandledException StackTrace : " + ex.StackTrace);
            logger.Fatal("Runtime terminating: {0}", e.IsTerminating);
        }        
    }


}

InformationsquelleAutor Developer

-3

Comme "VB de on Error Resume Next?" Que cela peut sembler un peu effrayant. La première recommandation est de ne pas le faire. Deuxième recommandation est de ne pas le faire et de ne pas y penser. Vous souhaitez isoler vos défauts mieux. Pour l'approche de ce problème, il dépend de la façon dont vous êtes le code est structuré. Si vous utilisez un modèle de type MVC ou alors ce ne devrait pas être trop difficile et serait certainement pas besoin d'un global d'exception avaleuse. Deuxièmement, pour trouver un bon bibliothèque de journalisation comme log4net ou utiliser le suivi. Nous aurions besoin de connaître plus de détails comme ce type d'exceptions dont vous parlez et ce que les parties de votre application peut entraîner l'exception levée.
- Le point est que je veux garder l'application en cours d'exécution, même après les exceptions non traitées. Je veux juste log (nous avons une coutume de journalisation pour cela, en fonction de nos besoins) et n'avez pas besoin d'interrompre l'ensemble du programme, juste parce que certains plugin fait quelque chose de bizarre dans son interaction avec l'utilisateur code. De ce que j'ai vu jusqu'à présent, il n'est pas trivial pour isoler les causes proprement que les différentes parties ne sais pas vraiment les uns des autres.
- Je comprends, mais vous devez être très prudent de continuer après qu'une exception vous de ne pas examiner, il y a la possibilité de corruption de données et ainsi de suite à prendre en compte.
- Je suis d'accord avec BobbyShaftoe. Ce n'est pas la bonne façon de procéder. Laissez le plantage de l'application. Si la faute est sur certains plugin, puis le fixer ou obtenir quelqu'un pour corriger le plugin. Laissant la course est EXTRÊMEMENT dangereux. Vous obtiendrez bizarre effets secondaires et atteignez un point où vous ne serez pas en mesure de trouver une explication logique pour les bugs qui se passe dans votre application.
- J'ai élaboré ce point un peu dans la question maintenant. Je connais les risques encourus, et pour une application particulière, il a été jugé acceptable. Et l'abandon de la demande pour quelque chose d'aussi simple qu'un indice hors limites, tandis que l'INTERFACE utilisateur a essayé de faire quelques belles animation est excessif et inutile. Oui, je ne sais pas la cause exacte, mais nous avons des données pour sauvegarder la réclamation que la grande majorité des cas d'erreur est bénigne. Les plus graves, nous sommes de masquage peut provoquer un dysfonctionnement de l'application, mais c'est ce qui se serait passé sans mondial de gestion de l'exception de toute façon.
InformationsquelleAutor BobbyShaftoe

Vous devez vous connecter pour publier un commentaire.