Capturar globalmente exceções em um aplicativo WPF?

Estamos tendo um aplicativo WPF em que partes dele podem gerar exceções em tempo de execução. Eu gostaria de capturar globalmente qualquer exceção não tratada e registrá-las, mas, caso contrário, continue a execução do programa como se nada tivesse acontecido (como os VBs On Error Resume Next).

Isso é possível em c #? E se sim, onde exatamente eu precisaria colocar o código de manipulação de exceções?

Atualmente, não consigo ver nenhum ponto em que eu possa quebrar um try/ catchao redor e que capte todas as exceções que possam ocorrer. E mesmo assim eu teria deixado o que foi executado por causa da captura. Ou estou pensando em direções terrivelmente erradas aqui?

ETA: Como muitas pessoas abaixo indicaram: O aplicativo não é para controlar usinas nucleares. Se travar, não é grande coisa, mas as exceções aleatórias relacionadas principalmente à interface do usuário são um incômodo no contexto em que seria usado. Havia (e provavelmente ainda existem) alguns deles, e como ele usa uma arquitetura de plug-in e pode ser estendido por outros (também estudantes nesse caso; portanto, não há desenvolvedores experientes capazes de escrever código completamente livre de erros).

Quanto às exceções detectadas: eu as registro em um arquivo de log, incluindo o rastreamento completo da pilha. Esse era o objetivo desse exercício. Apenas para combater as pessoas que estavam tomando minha analogia com a OERN da VB muito literalmente.

Eu sei que ignorar cegamente certas classes de erros é perigoso e pode corromper minha instância do aplicativo. Como dito anteriormente, este programa não é essencial para ninguém. Ninguém em sã consciência apostaria nela a sobrevivência da civilização humana. É simplesmente uma pequena ferramenta para testar determinadas abordagens de design. Engenharia de software.

Para o uso imediato do aplicativo, não há muitas coisas que podem acontecer em uma exceção:

• Sem tratamento de exceções - diálogo de erro e saída do aplicativo. A experiência deve ser repetida, embora provavelmente com outro assunto. Nenhum erro foi registrado, o que é lamentável.
• Tratamento genérico de exceção - erro benigno interceptado, nenhum dano causado. Este deve ser o caso comum julgado por todos os erros que estávamos vendo durante o desenvolvimento. Ignorar esse tipo de erro não deve ter consequências imediatas; as estruturas de dados principais são testadas o suficiente para sobreviverem facilmente a isso.
• Tratamento de exceção genérico - erro grave interceptado, possivelmente travar em um momento posterior. Isso pode acontecer raramente. Nós nunca vimos isso até agora. O erro é registrado de qualquer maneira e uma falha pode ser inevitável. Portanto, isso é conceitualmente semelhante ao primeiro caso. Exceto que temos um rastreamento de pilha. E na maioria dos casos, o usuário nem percebe.

Quanto aos dados do experimento gerados pelo programa: um erro grave na pior das hipóteses faria com que nenhum dado fosse registrado. Mudanças sutis que alteram um pouco o resultado do experimento são bastante improváveis. E mesmo nesse caso, se os resultados parecerem duvidosos, o erro foi registrado; ainda é possível jogar fora esse ponto de dados, se for um total discrepante.

Para resumir: Sim, eu me considero ainda pelo menos parcialmente sã e não considero uma rotina global de manipulação de exceções que deixa o programa em execução necessariamente necessariamente totalmente mau. Como dito duas vezes antes, essa decisão pode ser válida, dependendo da aplicação. Nesse caso, foi julgada uma decisão válida e não besteira total e absoluta. Para qualquer outro aplicativo, essa decisão pode parecer diferente. Mas, por favor, não me acuse ou a outras pessoas que trabalharam nesse projeto para potencialmente explodir o mundo só porque estamos ignorando erros.

Nota lateral: existe exatamente um usuário para esse aplicativo. Não é algo como o Windows ou o Office que é usado por milhões, onde o custo de ter exceções borbulhar para o usuário já seria muito diferente em primeiro lugar.

Use o Application.DispatcherUnhandledException Event . Veja esta pergunta para um resumo (consulte a resposta de Drew Noakes ).

Esteja ciente de que ainda haverá exceções que impedem a retomada bem-sucedida do seu aplicativo, como após um estouro de pilha, memória esgotada ou perda de conectividade de rede enquanto você tenta salvar no banco de dados.

Código de exemplo usando o NLog que capturará exceções lançadas de todos os threads no AppDomain , do thread do dispatcher interface usuário e das funções assíncronas :

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

Este evento fornece notificação de exceções não capturadas. Ele permite que o aplicativo registre informações sobre a exceção antes que o manipulador padrão do sistema relate a exceção ao usuário e encerre o aplicativo.

   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 o evento UnhandledException for tratado no domínio do aplicativo padrão, ele será gerado para qualquer exceção não tratada em qualquer encadeamento, independentemente do domínio do aplicativo em que o encadeamento foi iniciado. Se o encadeamento iniciado em um domínio de aplicativo que possui um manipulador de eventos para UnhandledException, o evento é gerado nesse domínio de aplicativo. Se esse domínio de aplicativo não for o domínio de aplicativo padrão e também houver um manipulador de eventos no domínio de aplicativo padrão, o evento será gerado nos dois domínios de aplicativo.

Por exemplo, suponha que um encadeamento inicie no domínio do aplicativo "AD1", chame um método no domínio do aplicativo "AD2" e, a partir daí, chame um método no domínio do aplicativo "AD3", onde ele lança uma exceção. O primeiro domínio do aplicativo no qual o evento UnhandledException pode ser gerado é "AD1". Se esse domínio de aplicativo não for o domínio de aplicativo padrão, o evento também poderá ser gerado no domínio de aplicativo padrão.

Além do que outros mencionaram aqui, observe que a combinação de Application.DispatcherUnhandledException(e seus similares ) com

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

no app.configimpedirá que a exceção de encadeamentos secundários encerre o aplicativo.

Aqui está um exemplo completo usando 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);
        }        
    }


}

Como "VB's On Error Resume Next?" Isso parece meio assustador. A primeira recomendação é não fazê-lo. A segunda recomendação é não fazê-lo e não pensar nisso. Você precisa isolar melhor suas falhas. Quanto à forma de abordar esse problema, isso depende de como o código está estruturado. Se você estiver usando um padrão como MVC ou similar, isso não deve ser muito difícil e definitivamente não exigiria um engolidor de exceção global. Em segundo lugar, procure uma boa biblioteca de log como log4net ou use rastreamento. Precisamos saber mais detalhes, como quais tipos de exceções você está falando e quais partes do seu aplicativo podem resultar no lançamento de exceções.