Какова должна быть лучшая Стратегия Обработки исключений

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

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

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

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

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

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

public enum AddCustomerResult
{
    Success,
    CustomerAlreadyExists,
    CustomerPreviouslyRetired
}

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

Это лишь одна из техник, которая хорошо работает для меня.

С исключениями вы хотите бросать их в исключительных обстоятельствах, и везде, где есть обход слоев (моя собственная конвенция, не знаю, насколько она верна), вы хотите ловить исключения и повторно бросать их с помощью пользовательского класса-обертки для этого слоя.

Например, в DAL вы хотите ловить исключения и отбрасывать их как внутреннее исключение на DataAccessException, возможно; в веб-сервисе вы обернете все свои методы в обработчики исключений, чтобы отбрасывать их с MyWebServiceException. В пользовательском интерфейсе (который проходит изнутри приложения до экрана пользователя) вы захотите поймать, зарегистрировать и выдать ему красивое сообщение. Насколько я могу судить, нет никаких причин ловить или отбрасывать ошибку где-либо еще.

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

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

Надеюсь, это поможет!

Что бы вы ни решили - будьте последовательны . Через 30 дней вы (или другой разработчик) должны будете понять свой код.

Кроме того, как Скотт Хансельман любит цитировать в своем подкасте (и я думаю, что это может быть в книге Beautiful Code) -

Все проблемы в информатике могут быть решены с помощью другого уровня косвенного обращения. , "- известная цитата, приписываемая Батлеру Лэмпсону, ученому, который в 1972 году придумал современный персональный компьютер.

Создание исключений обходится дорого. И мне нравится, когда мой бизнес-уровень имеет свое собственное специализированное исключение, которое может генерировать только он. Таким образом, это упрощает отслеживание. Например (вне моей головы, поскольку передо мной нет компилятора C #):

public class MyException : Exception
{
   private MyException(Exception ex, string msg) {
       this.Message = msg;
       this.InnerException = ex;
   }

   internal static MyException GetSomethingBadHappened(Exception ex, string someInfo) {
      return new MyException(ex, someInfo);
   }
}

Почти всегда стоит разделять обработку исключений и отчет об ошибках.

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

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

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

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

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