В каких случаях исключения не должны обрабатываться?

Question

Можно ли сформулировать руководство, чтобы ответить:

В каких случаях разработчик не должен обрабатывать конкретное исключение?

Чтобы выразить себя лучше, если метод ожидает одно из значений 1,2,3,4,5 для параметра: "Zeta" и с точки зрения бизнес-логики, если бессмысленно, что 9 не может быть перенесено в качестве значения параметра, должен ли разработчик по-прежнему обрабатывать возможное исключение аргумента?

Answer 1

если вы посмотрите документацию об исключениях из MSDN, в ней будет указано следующее:

• Не перехватывайте исключение, если вы не можете обработать его и оставить приложение в известном состоянии,Если вы перехватываете System.Exception, перезапустите его, используя ключевое слово throw в конце блока catch.

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

Если разработчик не может обработать ArgumentException, когда пройдено 9, он не должен его ловить.

Answer 2

Я буду несколько противоречить здесь, так как почти каждая рекомендация, которую я когда-либо видел, будет предлагать (иногда яростно), что вы должны проверять только определенные ожидаемые вами исключения («белый список» исключений, которые вы можете обработать).

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

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

try
{
    ...
}
catch(Exception ex)
{
    if (IsInBlackList(ex))
    {
       throw;
    }
    ... code to recover from exception ...
}

Прецеденты для этого есть в самой .NET Framework, например, System.Windows.Forms.Application.CommonAppDataPath делает именно это, используя внутренний метод ClientUtils.IsSecurityOrCriticalException для определения своего «черного списка».

Answer 3

В общем, следует избегать исключений.Так, например, вместо того, чтобы допустить исключение NullReferenceException, вместо этого проверьте null.Всегда проверяйте правильность всех своих аргументов и бросайте ArgumentException, если вы найдете недопустимые значения.

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

Answer 4

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