Это плохая практика для ловли неопределенного исключения, такого как Система. Исключение? Почему?

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

Иногда это только к способу обработать, "ловят каждое исключение" сценарии, на самом деле не ловя каждое исключение.

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

В этом случае возможный блок выгоды мог быть похожим на это:

try
{
   // User code called here
}
catch (Exception ex)
{
   if (ExceptionIsFatal(ex))
     throw;

   Log(ex);
}

Существует три важных момента здесь, однако:

1. Это не что-то для каждой ситуации. В обзорах кода мы очень требовательны в отношении мест, где это на самом деле необходимо и таким образом позволено.
2. ExceptionIsFatal () метод гарантирует, что мы не едим исключения, которые никогда нельзя глотать (ExecutionEngineException, OutOfMemoryException, ThreadAbortException, и т.д.)
3. То, что глотают, тщательно зарегистрировано (журнал событий, log4net, YMMV)

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

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

То, когда существует дублирующаяся логика как это, в чем Вы действительно нуждаетесь, является фильтром исключения, таким образом, Вы только ловите типы исключительной ситуации, Вы интересуетесь. VB.NET имеет эту функциональность, но к сожалению C# не делает. Гипотетический синтаксис мог бы быть похожим:

try
{
    // Call to a WebService
}
catch (Exception ex) if (ex is SoapException || ex is HttpException || /* etc. */)
{
    // Log Error and eat it
}

Поскольку Вы не можете сделать этого, хотя, то, что я склонен делать вместо этого, является использованием лямбда-выражение для общего кода (Вы могли использовать a delegate в C# 2.0), например.

Action<Exception> logAndEat = ex => 
    {  
        // Log Error and eat it
    };

try
{
    // Call to a WebService
}
catch (SoapException ex)
{
    logAndEat(ex);
}
catch (HttpException ex)
{
    logAndEat(ex);
}
catch (WebException ex)
{
    logAndEat(ex);
}

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

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

try
{
  // Do some work
}
catch (Exception ex)
{
  if (ex is SoapException)
  {
    // SoapException specific recovery actions
  }
  else if (ex is HttpException)
  {
    // HttpException specific recovery actions
  }
  else if (ex is WebException)
  {
    // WebException specific recoery actions
  }
  else
  {
    throw;
  }
}

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

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

Не полностью, посмотрите ниже.

• Поймайте универсальное исключение (Исключение исключая)

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

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

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

Однако от эстетики и удобочитаемости POV я предпочел бы несколько блоков выгоды "если (исключая SoapException ||..)". После того как Вы осуществляете рефакторинг общий код обработки в метод, несколько блоков выгоды незначительно больше вводят и легче читать для большинства разработчиков. Кроме того, заключительный бросок легко пропущен.

• Мы едим SoapException, HttpException и WebException. Но если веб-сервис перестал работать, там не очень, чтобы сделать.

Здесь возможно скрывается самая большая проблема кода, но трудно дать совет, не зная больше о природе приложения. Если вызов веб-сервиса делает что-то, от чего Вы зависите позже затем, вероятно, неправильно просто зарегистрировать и съесть исключения. Как правило, Вы позволяете исключению распространить вызывающей стороне (обычно после обертывания его в, например, XyzWebServiceDownException), возможно, даже после повторения веб-сервиса звонят несколько раз (чтобы быть более устойчивым, когда существуют побочные сетевые проблемы).