Как я могу глотать все исключения и защитить мое приложение от катастрофического отказа?

Вы не хотите перехватывать каждое исключение везде.

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

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

ComplexBuilder cb = new ComplexBuilder();
try
{
    cb.AddOperation(...);  // Once building starts,
    cb.AddOperation(...);  // it's not safe to use cb
    cb.AddOperation(...);
}
catch (SpecificException ex)
{
    cb.Cleanup();          // until it's cleaned up
}

// Now safe to access cb, whether or not an exception was thrown

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

Произошло то, что попытка чтения ресурса по какой-то причине не удалась. Это вернуло значение null вместо строкового ресурса.Это вызвало исключение ArgumentNullException в вызове String.Format . Это привело к тому, что исключение было перехвачено кодом, который только что продолжился.

Но между первым и последним исключением должен был быть выделен объект и должна была быть установлена ​​ссылка на объект. Но из-за исключения установка ссылки так и не произошла. В результате я увидел NullReferenceException , четыре уровня стека вверх и два файла .csproj от того места, где возникла реальная проблема.

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

AppDomain.UnHandledException и / или AppDomain.ThreadException - это события, на которые вы можете подписаться, чтобы перехватить необработанные исключения. Я не думаю, что вы можете использовать это, чтобы продолжить выполнение с того места, где оно было остановлено (и это, вероятно, в любом случае не будет хорошей идеей). Их можно использовать для проглатывания сообщения об ошибке, его регистрации и т. Д.

Однако решать, стоит ли это делать, решать вам!

Одним из способов избежать таких исключений является использование шаблона нулевого объекта .

Таким образом, вместо Account account = null; вы должны сделать Account account = Account.SpecialNullAccount; и в своем классе Account вы должны определить SpecialNullAccount как статический объект Account . Теперь, если вы попытаетесь использовать account.Name в каком-то несущественном коде (например, в коде регистрации), вы не получите Exception, вместо этого вы получите значение, например, «NO NAME», определенное в статическом экземпляр нулевого объекта.

Конечно, важно, чтобы такой объект ДЕЙСТВИТЕЛЬНО генерировал исключения в любом важном случае, например.PayInvoice () или objectContext.SaveChanges (), поэтому примите меры, чтобы это произошло.

вам, конечно же, не следует добавлять try catch везде

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

, если вам повезет, приложение может продолжить (повезло, поскольку у вас нет возможности узнать, действительно ли вы застряли в затруднительном положении)

обратите внимание, что вы также можете сделать это

        AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
        Forms.Application.ThreadException += new System.Threading.ThreadExceptionEventHandler(Application_ThreadException);

, но это не останавливает сбой, а просто позволяет зафиксировать сбой

Если это приложение Winforms, добавьте обработчики следующих событий в метод Main следующим образом

Application.ThreadException += Application_ThreadException;
AppDomain.CurrentDomain.UnhandledException += CurrentDomain_UnhandledException;

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

Это то, чего не понимают многие разработчики. К тому моменту, когда ваш catch-all для исключений достигнет цели, ваше приложение уже рухнет. Произошло что-то неожиданное, что означает, что ваш код не предвидел этого, и, скорее всего, ситуация находится в неопределенном состоянии (т.е. вы не можете точно сказать, какая часть нарушающей функции завершилась в момент генерации исключения, вы не знаете, сколько данных было записано, какие биты были установлены в аппаратном обеспечении и т.д.). Безопасно ли продолжать работу? Стоит ли пытаться спасти данные пользователя? Кто знает!

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

Это приложение выполнило незаконную операцию

... но чем ваше пользовательское сообщение будет лучше?

Мы завершаем работу без предупреждения для внепланового обслуживания, но будьте будьте уверены, что это не имеет никакого отношения к дефектом в этом превосходном программном обеспечении

...?