Не будет ли лучше обрабатывать исключение

Question

1)

1 - обрабатывать только те исключения, которые вы на самом деле может что-то делать, и
2 - Вы ничего не можете сделать с подавляющим большинством исключений

a) Я предполагаю, что “By not handling an exception” текст предполагает, что мы должны позволить исключению пузыриться в стеке, где среда выполнения прервет наше приложение?!

b) Но почему разрешить среде выполнения прервать исключение, а не перехватить его, записать в журнал и затем сообщить пользователю об ошибке? Единственная разница между ними заключается в том, что в последнем случае приложение не прерывается

Например, если база данных выходит из строя, почему должна произойти сбой всей программы (из-за отсутствия обработки исключения), если мы вместо этого можем перехватить исключение, зарегистрировать его и уведомить пользователя о сбое, и таким образом мы можем поддерживать программу работоспособной и работает

2) Если вы знаете, что исключение, которое может быть вызвано каким-либо блоком кода, не может быть обработано, следует ли включать этот код в блок try-finally или лучше оставить его вне блоков try-finally?

Спасибо

Answer 1

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

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

Answer 2

Попробуйте посмотреть на это так ... База данных выключается.Откуда вы знаете?Потому что вы получаете тайм-аут / исключение / что-то.Но ваше приложение, вероятно, не получает исключения.ADO.NET/Linq to SQL / Entity Framework / Независимо от того, какой поставщик данных вы используете, вы получаете исключение и отправляете его в ваше приложение.Для меня это то, что советует этот совет: как разработчик компонента, предпочитайте выбрасывать исключения, с которыми вы ничего не можете сделать.

В примере с базой данных есть ли что-нибудь, что может провайдер данных ADO.NETделать?Может ли это восстановить сервер?Ремонт сетевых подключений?Сбросить разрешения?Так что это не обрабатывает исключение, оно бросает его.

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

Answer 3

Без знания контекста обоих утверждений указано, что оба утверждения относятся к методам и классам, тогда они имеют смысл:

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

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

Answer 4

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

Например, один и тот же бизнес-код / ​​код базы данных может использоваться в веб-приложении, и приложение windows / wpf и ведение журнала / обработка могут отличаться, и более глубокие слои не знают, как это будет обрабатываться, поэтому им необходимо оставьте ответственность на уровне пользовательского интерфейса .

Answer 5

Я думаю, что ключ к

Обрабатывать только те исключения, которые вы действительно можете сделать с

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

Для простейшего примера.

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

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

Answer 6

Дело в том, что вы не хотите, чтобы блоки try / catch были вложены в ваш код везде, поскольку это имеет тенденцию скрывать проблемы с вашим кодом. Лучше реализовывать обработку исключений только тогда, когда вы понимаете ошибку и желаемый результат, иначе не обрабатываете ее и не позволяете ей всплыть.

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

Событие для подключения приложения .net win win:

AppDomain.CurrentDomain.UnhandledException

Событие для подключения к приложению .net asp.net:

HttpApplication.Error

Наслаждайтесь!

Answer 7

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

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