Catturare globalmente le eccezioni in un'applicazione WPF?

Stiamo avendo un'applicazione WPF in cui parti di essa possono generare eccezioni in fase di esecuzione. Vorrei catturare globalmente qualsiasi eccezione non gestita e registrarle, ma altrimenti continuare l'esecuzione del programma come se nulla fosse successo (un po 'come VB On Error Resume Next).

È possibile in C #? E se sì, dove dovrei esattamente inserire il codice di gestione delle eccezioni?

Al momento non riesco a vedere nessun singolo punto in cui posso avvolgere un try/ catcharound e che catturerebbe tutte le eccezioni che potrebbero verificarsi. E anche allora avrei lasciato tutto ciò che è stato eseguito a causa della cattura. O sto pensando in direzioni orribilmente sbagliate qui?

ETA: Perché molte persone sotto lo hanno sottolineato: L'applicazione non è per il controllo di centrali nucleari. Se si arresta in modo anomalo non è un grosso problema, ma le eccezioni casuali che sono per lo più correlate all'interfaccia utente sono un fastidio nel contesto in cui verrebbero utilizzate. Ce n'erano (e probabilmente lo sono ancora) alcuni di questi e poiché utilizza un'architettura plug-in e potrebbe essere esteso da altri (anche studenti in quel caso; quindi nessuno sviluppatore esperto in grado di scrivere codice completamente privo di errori).

Per quanto riguarda le eccezioni che vengono rilevate: le registro in un file di registro, inclusa la traccia dello stack completa. Questo era il punto centrale di quell'esercizio. Solo per contrastare quelle persone che stavano prendendo alla lettera la mia analogia con OERN di VB.

So che ignorare ciecamente determinate classi di errori è pericoloso e potrebbe corrompere la mia istanza dell'applicazione. Come detto prima, questo programma non è fondamentale per nessuno. Nessuno nella loro mente giusta avrebbe scommesso su di essa la sopravvivenza della civiltà umana. È semplicemente un piccolo strumento per testare alcuni approcci progettuali. Ingegneria software.

Per l'uso immediato dell'applicazione non ci sono molte cose che possono accadere su un'eccezione:

• Nessuna gestione delle eccezioni: finestra di dialogo di errore e uscita dell'applicazione. L'esperimento deve essere ripetuto, sebbene probabilmente con un'altra materia. Non sono stati registrati errori, il che è un peccato.
• Gestione generica delle eccezioni: errore benigno bloccato, nessun danno fatto. Questo dovrebbe essere il caso comune giudicato da tutti gli errori che abbiamo riscontrato durante lo sviluppo. Ignorare questo tipo di errori non dovrebbe avere conseguenze immediate; le strutture di dati di base sono testate abbastanza bene da poter sopravvivere facilmente.
• Gestione generica delle eccezioni: errore grave intercettato, possibilmente arresto anomalo in un secondo momento. Questo può succedere raramente. Non l'abbiamo mai visto finora. L'errore viene comunque registrato e un arresto potrebbe essere inevitabile. Quindi questo è concettualmente simile al primo caso. Solo che abbiamo una traccia di stack. E nella maggior parte dei casi l'utente non se ne accorgerà nemmeno.

Per quanto riguarda i dati dell'esperimento generati dal programma: un grave errore causerebbe nella peggiore delle ipotesi la registrazione di dati. Lievi modifiche che cambiano leggermente leggermente il risultato dell'esperimento sono abbastanza improbabili. E anche in quel caso, se i risultati sembrano dubbi, l'errore è stato registrato; si può ancora buttare via quel punto dati se si tratta di un valore anomalo totale.

Riassumendo: Sì, mi considero ancora almeno parzialmente sano e non considero una routine globale di gestione delle eccezioni che lasci il programma in esecuzione necessariamente necessariamente malvagio. Come già detto due volte, tale decisione potrebbe essere valida, a seconda dell'applicazione. In questo caso è stata giudicata una decisione valida e non una cazzata totale e totale. Per qualsiasi altra applicazione tale decisione potrebbe apparire diversa. Ma per favore non accusare me o le altre persone che hanno lavorato a quel progetto per far esplodere il mondo solo perché stiamo ignorando gli errori.

Nota a margine: esiste esattamente un utente per quell'applicazione. Non è qualcosa come Windows o Office che viene utilizzato da milioni di persone in cui il costo di avere eccezioni a tutti gli utenti sarebbe già molto diverso.

Usa il Application.DispatcherUnhandledException Event. Vedi questa domanda per un riepilogo (vedi la risposta di Drew Noakes ).

Tenere presente che ci saranno ancora delle eccezioni che impediscono il corretto ripristino dell'applicazione, ad esempio dopo un overflow dello stack, memoria esaurita o perdita della connettività di rete durante il tentativo di salvare nel database.

Codice di esempio che utilizza NLog che rileverà le eccezioni generate da tutti i thread in AppDomain , dal thread del dispatcher dell'interfaccia utente e dalle funzioni asincrone :

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

Evento AppDomain.UnhandledException

Questo evento fornisce la notifica di eccezioni non rilevate. Consente all'applicazione di registrare le informazioni sull'eccezione prima che il gestore predefinito del sistema segnali l'eccezione all'utente e termini l'applicazione.

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

Se l'evento UnhandledException viene gestito nel dominio dell'applicazione predefinito, viene generato lì per qualsiasi eccezione non gestita in qualsiasi thread, indipendentemente dal dominio dell'applicazione in cui è stato avviato il thread. Se il thread è stato avviato in un dominio dell'applicazione che ha un gestore eventi per UnhandledException, l'evento viene generato in quel dominio dell'applicazione. Se quel dominio dell'applicazione non è il dominio dell'applicazione predefinito e esiste anche un gestore eventi nel dominio dell'applicazione predefinito, l'evento viene generato in entrambi i domini dell'applicazione.

Ad esempio, supponiamo che un thread inizi nel dominio dell'applicazione "AD1", chiama un metodo nel dominio dell'applicazione "AD2" e da lì chiama un metodo nel dominio dell'applicazione "AD3", dove genera un'eccezione. Il primo dominio dell'applicazione in cui è possibile generare l'evento UnhandledException è "AD1". Se quel dominio dell'applicazione non è il dominio dell'applicazione predefinito, l'evento può anche essere generato nel dominio dell'applicazione predefinito.

Inoltre, ciò che altri hanno menzionato qui, nota che combinando il Application.DispatcherUnhandledException(e i suoi simili ) con

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

nel app.configimpedirà il tuo eccezione discussioni secondaria di arrestare l'applicazione.

Ecco un esempio completo di utilizzo 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);
        }        
    }


}

Come "VB's On Error Riprendi Next?" Sembra un po 'spaventoso. La prima raccomandazione è non farlo. La seconda raccomandazione è non farlo e non pensarci. Devi isolare meglio i tuoi difetti. Per quanto riguarda come affrontare questo problema, dipende da come è strutturato il codice. Se stai usando un modello come MVC o simili, questo non dovrebbe essere troppo difficile e sicuramente non richiederebbe un swallower di eccezione globale. In secondo luogo, cerca una buona libreria di log come log4net o usa la traccia. Dovremmo avere maggiori dettagli come il tipo di eccezioni di cui stai parlando e quali parti della tua applicazione potrebbero comportare il lancio di eccezioni.