Attraper globalement des exceptions dans une application WPF?

Nous avons une application WPF dont certaines parties peuvent lever des exceptions lors de l'exécution. J'aimerais intercepter globalement toute exception non gérée et les enregistrer, mais sinon, continuez l'exécution du programme comme si rien ne s'était passé (un peu comme les VB On Error Resume Next).

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

Actuellement, je ne vois aucun point unique où je pourrais boucler un try/ catchautour et qui intercepterait toutes les exceptions qui pourraient se produire. Et même alors, j'aurais laissé tout ce qui a été exécuté à cause de la capture. Ou est-ce que je pense ici dans des directions horriblement erronées?

ETA: Parce que de nombreuses personnes ci-dessous l'ont souligné: L'application n'est pas destinée au contrôle des centrales nucléaires. S'il se bloque, ce n'est pas très grave, mais des exceptions aléatoires qui sont principalement liées à l'interface utilisateur sont une nuisance dans le contexte où il serait utilisé. Il y en avait (et il y en a probablement encore) et comme il utilise une architecture de plug-in et peut être étendu par d'autres (également des étudiants dans ce cas; donc pas de développeurs expérimentés capables d'écrire du code sans erreur).

Quant aux exceptions qui sont interceptées: je les enregistre dans un fichier journal, y compris la trace de pile complète. C'était tout l'intérêt de cet exercice. Juste pour contrer ces gens qui prenaient mon analogie avec OERN de VB trop littéralement.

Je sais qu'ignorer aveuglément certaines classes d'erreurs est dangereux et peut corrompre mon instance d'application. Comme dit précédemment, ce programme n'est essentiel à la mission de personne. Personne sain d'esprit ne parierait la survie de la civilisation humaine dessus. C'est simplement un petit outil pour tester certaines approches de conception par rapport à. 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:

• Aucune gestion des exceptions - boîte de dialogue d'erreur et sortie de l'application. L'expérience doit être répétée, mais probablement avec un autre sujet. Aucune erreur n'a été enregistrée, ce qui est regrettable.
• Gestion des exceptions générique - erreur bénigne piégée, aucun dommage causé. Cela devrait être le cas commun à en juger par toutes les erreurs que nous avons vues pendant le développement. Ignorer ce type d'erreurs ne devrait pas avoir de conséquences immédiates; les structures de données de base sont suffisamment testées pour pouvoir y survivre facilement.
• Gestion des exceptions générique - erreur grave interceptée, peut-être planter ultérieurement. Cela peut arriver rarement. Nous ne l'avons jamais vu jusqu'à présent. L'erreur est enregistrée de toute façon et un plantage peut être inévitable. C'est donc conceptuellement similaire au tout premier cas. Sauf que nous avons une trace de pile. Et dans la majorité des cas, l'utilisateur ne le remarquera même pas.

En ce qui concerne les données d'expérience générées par le programme: Une erreur grave entraînerait au pire le fait qu'aucune donnée ne soit enregistrée. Des changements subtils qui modifient légèrement le résultat de l'expérience sont très peu probables. 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 s'il s'agit d'une valeur aberrante totale.

Pour résumer: Oui, je me considère toujours au moins partiellement sain d'esprit et je ne considère pas une routine globale de gestion des exceptions qui laisse le programme en cours d'exécution être nécessairement totalement mauvais. Comme indiqué deux fois auparavant, une telle décision peut être valable, selon l'application. Dans ce cas, il a été jugé une décision valide et non une connerie totale et totale. Pour toute autre application, cette décision peut sembler différente. Mais s'il vous plaît, n'accusez pas moi ou les autres personnes qui ont travaillé sur ce projet pour potentiellement faire exploser le monde simplement parce que nous ignorons les erreurs.

Note latérale: 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 de la bulle d'exceptions pour l'utilisateur serait déjà très différent en premier lieu.

Utilisez le Application.DispatcherUnhandledException Event. Voir cette question pour un résumé (voir la réponse de Drew Noakes ).

Sachez qu'il y aura toujours des exceptions qui empêcheront une reprise réussie de votre application, comme après un débordement de pile, une mémoire épuisée ou une perte de connectivité réseau pendant que vous essayez d'enregistrer dans la base de données.

Exemple de code utilisant NLog qui interceptera les exceptions levées de tous les threads de l'AppDomain , du thread du répartiteur d'interface utilisateur et des fonctions asynchrones :

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");
            e.Handled = true;
        };

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

    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);
        }
    }

AppDomain.UnhandledException, événement

Cet événement fournit une notification des exceptions non interceptées. Il permet à l'application de consigner des informations sur l'exception avant que le gestionnaire par défaut du système ne signale l'exception à l'utilisateur et ne ferme l'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 l'événement UnhandledException est géré dans le domaine d'application par défaut, il y est déclenché pour toute exception non gérée dans n'importe quel thread, quel que soit le domaine d'application dans lequel le thread a démarré. Si le thread a démarré dans un domaine d'application doté d'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 le domaine d'application par défaut et qu'il existe également un gestionnaire d'événements dans le domaine d'application par défaut, 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à appelle une méthode dans le domaine d'application "AD3", où il lève une exception. Le premier domaine d'application dans lequel l'événement UnhandledException peut être déclenché est "AD1". Si ce domaine d'application n'est pas le domaine d'application par défaut, l'événement peut également être déclenché dans le domaine d'application par défaut.

En plus de ce que d'autres ont mentionné ici, notez que la combinaison Application.DispatcherUnhandledException(et ses similitudes ) avec

<configuration>
  <runtime>  
    <legacyUnhandledExceptionPolicy enabled="1" />
  </runtime>
</configuration>

dans le app.configvous empêchera votre exception de threads secondaires de fermer l'application.

Voici un exemple complet utilisant 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);
        }        
    }


}

Comme "VB's On Error Resume Next?" Cela semble un peu effrayant. La première recommandation est de ne pas le faire. La deuxième recommandation est de ne pas le faire et de ne pas y penser. Vous devez mieux isoler vos défauts. Quant à la façon d'aborder ce problème, cela dépend de la façon dont votre code est structuré. Si vous utilisez un modèle comme MVC ou similaire, cela ne devrait pas être trop difficile et ne nécessiterait certainement pas un avaleur d'exceptions global. Deuxièmement, recherchez une bonne bibliothèque de journalisation comme log4net ou utilisez le traçage. Nous aurions besoin de plus de détails, tels que les types d'exceptions dont vous parlez et les parties de votre application susceptibles d'entraîner la levée d'exceptions.