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

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

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

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

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 вместо string ресурса. Это вызвало ArgumentNullException на String.Format звонок. Это привело к тому, что исключение было поймано кодом, который просто продолжался.

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

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

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

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

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

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

мы закрываемся без предупреждения для внепланового обслуживания, но отдыха уверял, что так и было!--3-->ничего общего с недостаток в этом отличном программном обеспечении

...?

вы, конечно, не должны добавлять try catch everywhere

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

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

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

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

но это не останавливает его crshing, он просто позволяет захватить сбой

один из способов избежать таких исключений-использовать шаблон null объект.

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

конечно, это важно что такой объект делает исключения в любом важном случае, как .PayInvoice () или objectContext.SaveChanges () поэтому примите меры, чтобы это произошло.

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

ли это хорошая идея, чтобы сделать это до вас, однако!

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

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

затем вы можете показать messagebox или другое уведомление, loog exeception и т. д. и продолжить работу без сбоев приложения.