¿Captura excepciones a nivel mundial en una aplicación WPF?

Tenemos una aplicación WPF donde partes de ella pueden generar excepciones en tiempo de ejecución. Me gustaría detectar globalmente cualquier excepción no controlada y registrarla, pero de lo contrario continuar con la ejecución del programa como si nada sucediera (algo así como VB On Error Resume Next).

¿Es esto posible en C #? Y si es así, ¿dónde exactamente necesitaría poner el código de manejo de excepciones?

Actualmente no puedo ver ningún punto único en el que pueda ajustar un try/ catchalrededor y que atrape todas las excepciones que puedan ocurrir. Y aun así, habría dejado todo lo que se ha ejecutado debido a la captura. ¿O estoy pensando en direcciones horriblemente incorrectas aquí?

ETA: Porque muchas personas a continuación lo señalaron: la aplicación no es para controlar plantas de energía nuclear. Si se bloquea, no es un gran problema, pero las excepciones aleatorias que están relacionadas principalmente con la interfaz de usuario son una molestia en el contexto en el que se usarían. Hubo (y probablemente todavía hay) algunos de ellos, ya que utiliza una arquitectura de complemento y puede ser extendido por otros (también estudiantes en ese caso; por lo tanto, no hay desarrolladores experimentados que puedan escribir código completamente libre de errores).

En cuanto a las excepciones que quedan atrapadas: las registro en un archivo de registro, incluida la traza completa de la pila. Ese fue el objetivo de ese ejercicio. Solo para contrarrestar a esas personas que estaban tomando mi analogía con el OERN de VB demasiado literalmente.

Sé que ignorar ciegamente ciertas clases de errores es peligroso y podría corromper mi instancia de aplicación. Como se dijo antes, este programa no es de misión crítica para nadie. Nadie en su sano juicio apostaría por la supervivencia de la civilización humana. Es simplemente una pequeña herramienta para probar ciertos enfoques de diseño wrt. Ingeniería de software.

Para el uso inmediato de la aplicación, no hay muchas cosas que puedan suceder en una excepción:

• Sin manejo de excepciones: diálogo de error y salida de la aplicación. El experimento tiene que repetirse, aunque probablemente con otro sujeto. No se han registrado errores, lo cual es lamentable.
• Manejo genérico de excepciones: error benigno atrapado, sin daño. Este debería ser el caso común a juzgar por todos los errores que estábamos viendo durante el desarrollo. Ignorar este tipo de errores no debería tener consecuencias inmediatas; Las estructuras de datos centrales se prueban lo suficientemente bien como para sobrevivir fácilmente a esto.
• Manejo de excepciones genéricas: error grave atrapado, posiblemente bloqueado en un momento posterior. Esto puede suceder raramente. Nunca lo hemos visto hasta ahora. El error se registra de todos modos y un bloqueo puede ser inevitable. Entonces, esto es conceptualmente similar al primer caso. Excepto que tenemos un seguimiento de pila. Y en la mayoría de los casos, el usuario ni siquiera lo notará.

En cuanto a los datos del experimento generados por el programa: un error grave en el peor de los casos solo provocaría que no se registraran datos. Los cambios sutiles que cambian el resultado del experimento muy ligeramente son bastante improbables. E incluso en ese caso, si los resultados parecen dudosos, se registra el error; aún se puede descartar ese punto de datos si es un valor atípico total.

Para resumir: Sí, me considero todavía al menos parcialmente cuerdo y no considero una rutina de manejo de excepciones global que deje el programa en ejecución necesariamente necesariamente malo. Como se dijo dos veces antes, tal decisión podría ser válida, dependiendo de la aplicación. En este caso se juzgó una decisión válida y no una mierda total y absoluta. Para cualquier otra aplicación, esa decisión podría verse diferente. Pero, por favor, no me acusen a mí ni a las otras personas que trabajaron en ese proyecto para hacer explotar el mundo potencialmente solo porque estamos ignorando errores.

Nota al margen: hay exactamente un usuario para esa aplicación. No es algo como Windows u Office que usan millones donde el costo de tener excepciones para el usuario sería muy diferente en primer lugar.

Usa el Application.DispatcherUnhandledException Event. Vea esta pregunta para un resumen (vea la respuesta de Drew Noakes ).

Tenga en cuenta que todavía habrá excepciones que impiden la reanudación exitosa de su aplicación, como después de un desbordamiento de pila, memoria agotada o pérdida de conectividad de red mientras intenta guardar en la base de datos.

Código de ejemplo que usa NLog que capturará excepciones lanzadas desde todos los subprocesos en el dominio de aplicación , desde el subproceso del despachador de la interfaz de usuario y desde las funciones así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);
        }
    }

AppDomain.UnhandledException Event

Este evento proporciona notificación de excepciones no detectadas. Permite que la aplicación registre información sobre la excepción antes de que el controlador predeterminado del sistema informe la excepción al usuario y finalice la aplicación.

   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 el evento UnhandledException se maneja en el dominio de aplicación predeterminado, se genera allí para cualquier excepción no controlada en cualquier hilo, sin importar en qué dominio de aplicación se haya iniciado el hilo. Si el hilo se inició en un dominio de aplicación que tiene un controlador de eventos para UnhandledException, el evento se genera en ese dominio de aplicación. Si ese dominio de aplicación no es el dominio de aplicación predeterminado, y también hay un controlador de eventos en el dominio de aplicación predeterminado, el evento se genera en ambos dominios de aplicación.

Por ejemplo, suponga que un subproceso comienza en el dominio de aplicación "AD1", llama a un método en el dominio de aplicación "AD2" y desde allí llama a un método en el dominio de aplicación "AD3", donde arroja una excepción. El primer dominio de aplicación en el que se puede generar el evento UnhandledException es "AD1". Si ese dominio de aplicación no es el dominio de aplicación predeterminado, el evento también se puede generar en el dominio de aplicación predeterminado.

Además de lo que otros mencionaron aquí, tenga en cuenta que la combinación de Application.DispatcherUnhandledException(y sus similares ) con

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

en el app.configevitará que la excepción de subprocesos secundarios cierre la aplicación.

Aquí hay un ejemplo 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 en error reanudar después?" Eso suena un poco aterrador. La primera recomendación es no hacerlo. La segunda recomendación es no hacerlo y no pensar en ello. Necesita aislar mejor sus fallas. En cuanto a cómo abordar este problema, depende de cómo esté estructurado su código. Si está utilizando un patrón como MVC o similar, entonces esto no debería ser demasiado difícil y definitivamente no requeriría una deglución de excepción global. En segundo lugar, busque una buena biblioteca de registro como log4net o use el rastreo. Necesitaríamos conocer más detalles, como qué tipo de excepciones está hablando y qué partes de su aplicación pueden generar excepciones.