Глобально ловить исключения в приложении WPF?

У нас есть приложение WPF, где его части могут генерировать исключения во время выполнения. Я хотел бы глобально перехватить любое необработанное исключение и записать их в журнал, но в противном случае продолжить выполнение программы, как будто ничего не произошло (вроде как в VB On Error Resume Next).

Возможно ли это в C #? И если да, то где именно мне нужно поместить код обработки исключений?

В настоящее время я не вижу какой-либо одной точки, где я мог бы обернуть try/ catchвокруг, и которая поймала бы все исключения, которые могли произойти. И даже тогда я бы оставил все, что было выполнено из-за улова. Или я здесь думаю в совершенно неправильном направлении?

ETA: Потому что многие люди ниже указали на это: приложение не для управления атомными электростанциями. Если он выходит из строя, это не так уж важно, но случайные исключения, которые в основном связаны с пользовательским интерфейсом, являются неприятностью в контексте, где он будет использоваться. Их было (и, вероятно, все еще осталось) несколько, и, поскольку они используют архитектуру плагинов и могут быть расширены другими (в данном случае также учащимися; так что нет опытных разработчиков, способных написать абсолютно безошибочный код).

Что касается обнаруженных исключений: я записываю их в файл журнала, включая полную трассировку стека. В этом весь смысл этого упражнения. Просто чтобы противостоять тем людям, которые слишком буквально воспринимали мою аналогию с OERN VB.

Я знаю, что слепое игнорирование определенных классов ошибок опасно и может повредить экземпляр моего приложения. Как уже было сказано, эта программа ни для кого не важна. Никто в здравом уме не поставил бы на это выживание человеческой цивилизации. Это просто маленький инструмент для тестирования определенных подходов к дизайну. разработка программного обеспечения.

Для немедленного использования приложения не так много вещей, которые могут произойти с исключением:

• Нет обработки исключений - диалог ошибок и выход из приложения. Эксперимент должен быть повторен, хотя, вероятно, с другим предметом. Ошибки не были зарегистрированы, что вызывает сожаление.
• Обработка исключений общего характера - доброкачественная ошибка в ловушке, никакого вреда не причинено. Это должно быть обычным делом, судя по всем ошибкам, которые мы видели во время разработки. Игнорирование ошибок такого рода не должно иметь немедленных последствий; основные структуры данных проверены достаточно хорошо, чтобы они могли легко пережить это.
• Обработка исключений общего характера - серьезная ошибка в ловушке, возможно сбой на более позднем этапе. Такое может случаться редко. Мы никогда не видели это до сих пор. В любом случае ошибка регистрируется, и сбой может быть неизбежным. Так что это концептуально похоже на самый первый случай. За исключением того, что у нас есть трассировка стека. И в большинстве случаев пользователь даже не заметит.

Что касается экспериментальных данных, сгенерированных программой: серьезная ошибка в худшем случае просто не приведет к записи данных. Незначительные изменения, которые слегка изменяют результат эксперимента, маловероятны. И даже в том случае, если результаты кажутся сомнительными, ошибка регистрировалась; все еще можно отбросить эту точку данных, если она является полным выбросом.

Подводя итог: Да, я считаю себя все еще, по крайней мере, частично вменяемым, и я не считаю, что глобальная подпрограмма обработки исключений, которая оставляет работающую программу, обязательно является абсолютно злой. Как уже было сказано дважды, такое решение может быть действительным, в зависимости от приложения. В данном случае было вынесено верное решение, а не полная и полная чушь. Для любого другого приложения это решение может выглядеть иначе. Но, пожалуйста, не обвиняйте меня или других людей, которые работали над этим проектом, чтобы потенциально взорвать мир только потому, что мы игнорируем ошибки.

Примечание: для этого приложения есть только один пользователь. Это не что-то вроде Windows или Office, которым пользуются миллионы, когда стоимость получения пузырей исключений для пользователя будет совсем другой, во-первых.

Используйте Application.DispatcherUnhandledException Event. См. Этот вопрос для краткого изложения (см. Ответ Дрю Ноакс ).

Имейте в виду, что все еще будут исключения, которые препятствуют успешному возобновлению работы вашего приложения, например, после переполнения стека, исчерпания памяти или потери сетевого подключения, пока вы пытаетесь сохранить в базу данных.

Пример кода с использованием NLog, который будет перехватывать исключения, генерируемые из всех потоков в AppDomain , из потока диспетчера пользовательского интерфейса и из асинхронных функций :

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

Это событие предоставляет уведомление о необработанных исключениях. Это позволяет приложению регистрировать информацию об исключении до того, как системный обработчик по умолчанию сообщит об исключении пользователю и завершит работу приложения.

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

Если событие UnhandledException обрабатывается в домене приложения по умолчанию, оно создается там для любого необработанного исключения в любом потоке, независимо от того, в каком домене приложения запущен поток. Если поток запущен в домене приложения, в котором есть обработчик события для UnhandledException, событие возникает в этом домене приложения. Если этот домен приложения не является доменом приложения по умолчанию, и в домене приложения по умолчанию также имеется обработчик события, событие возникает в обоих доменах приложения.

Например, предположим, что поток запускается в домене приложения «AD1», вызывает метод в домене приложения «AD2» и оттуда вызывает метод в домене приложения «AD3», где он вызывает исключение. Первый домен приложения, в котором может возникнуть событие UnhandledException, - «AD1». Если этот домен приложения не является доменом приложения по умолчанию, событие также может быть вызвано в домене приложения по умолчанию.

Кроме того, что другие упоминали здесь, обратите внимание, что объединение Application.DispatcherUnhandledException(и его аналог ) с

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

В этом app.configслучае исключение вторичных потоков не сможет завершить работу приложения.

Вот полный пример использования 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);
        }        
    }


}

Как "VB в случае ошибки продолжить дальше?" Это звучит немного страшно. Первая рекомендация - не делай этого. Вторая рекомендация - не делай этого и не думай об этом. Вы должны лучше изолировать свои недостатки. От того, как решить эту проблему, зависит то, как ваш код структурирован. Если вы используете шаблон, такой как MVC или тому подобное, то это не должно быть слишком сложно и определенно не потребует проглотителя глобальных исключений. Во-вторых, найдите хорошую библиотеку журналов, такую ​​как log4net, или используйте трассировку. Нам нужно знать больше деталей, например, о каких исключениях вы говорите и какие части вашего приложения могут привести к созданию исключений.