Глобально ловити винятки у програмі WPF?

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

Чи можливо це в C #? І якщо так, то де саме мені потрібно поставити код обробки винятків?

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

ETA: Оскільки багато людей нижче вказали на це: додаток не для управління атомними електростанціями. Якщо вона виходить з ладу, це не так вже й велика справа, але випадкові винятки, що стосуються переважно інтерфейсу користувача, викликають неприємності в контексті, де вона буде використовуватися. Було (і, мабуть, все ще) декілька з них, і оскільки вона використовує архітектуру плагінів і може бути розширена іншими (також студенти в цьому випадку, тому немає досвідчених розробників, які можуть написати повністю код без помилок).

Що стосується винятків, які потрапляють: я реєструю їх у файлі журналу, включаючи повний слід стека. В цьому і полягала вся суть цієї вправи. Просто для протидії тим людям, які надто буквально сприймали мою аналогію до VERN's OERN.

Я знаю, що сліпе ігнорування певних класів помилок небезпечно і може пошкодити екземпляр моєї програми. Як говорилося раніше, ця програма не є критичною для будь-якої місії. Ніхто з їх розумного розуму не став би на це виживання людської цивілізації. Це просто невеликий інструмент для тестування певних підходів до проектування. розробка програмного забезпечення.

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

• Не виняток - обробка помилок та вихід із програми. Експеримент потрібно повторити, хоча ймовірно з іншою темою. Жодних помилок не було зафіксовано, що шкода.
• Загальне поводження з винятками - доброякісна помилка в пастці, шкоди не завдано. Це має бути загальний випадок, який судять з усіх помилок, які ми спостерігали під час розробки. Ігнорування подібних помилок не повинно мати негайних наслідків; основні структури даних перевірені досить добре, щоб вони легко пережили це.
• Загальне поводження з винятками - серйозна помилка в пастці, можливо, аварія в більш пізній момент. Це може траплятися рідко. Ми ніколи цього не бачили. Помилка реєструється в будь-якому випадку, і збій може бути неминучим. Тож це концептуально схоже на перший випадок. За винятком того, що у нас є слід стека. І в більшості випадків користувач навіть не помітить.

Що стосується даних експерименту, згенерованих програмою: Серйозна помилка, в гіршому випадку, просто не призведе до запису даних. Тонкі зміни, які так незначно змінюють результат експерименту, є малоймовірними. І навіть у тому випадку, якщо результати здаються сумнівними, помилка була зафіксована; все-таки можна викинути цю точку даних, якщо це тотальний вигляд.

Підводячи підсумок: Так, я вважаю себе як мінімум частково здоровим, і не вважаю глобальну процедуру поводження з винятками, яка залишає програму обов'язково абсолютно злою. Як було сказано двічі раніше, таке рішення може бути дійсним, залежно від заявки. У цьому випадку його судили правильним рішенням, а не тотальним і повним глупотою. Для будь-якої іншої програми це рішення може виглядати інакше. Але, будь ласка, не звинувачуйте мене чи інших людей, які працювали над цим проектом, щоб потенційно підірвати світ лише тому, що ми ігноруємо помилки.

Побічна примітка: Для цього додатка існує точно один користувач. Це не щось на зразок 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, або використовуйте калькування. Нам потрібно знати більше деталей, наприклад, про які винятки, про які ви говорите, і які частини вашої програми можуть призвести до викидів виключень.