Неплохая практика заключается в том, чтобы вложить 2 команды catch catch в С#?

Является ли следующая неправильная практика кода?

 try //Try Overall Operation
      {
           try //Try section 1 of operation
               {

               }
           catch(exception ex)
               {
                    //handle exception code
                    //throw the exception
       }
 catch (exception ex)
      {
          // send soap exception back to SOAP client.
      }

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

Спасибо, ребята, я согласен с вами по поводу рефакторинга, создав отдельный метод для вспомогательной функциональности, метод стал очень длинным. Я очень впечатлен всем, кто выбрал это...

Ответ 1

Нет. Я не думаю, что это плохая практика.

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

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

Ответ 2

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

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

Ответ 3

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

Ответ 4

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

try
{ 
     // Do something 
     try
     {
         // Do something
     }
     catch(MyException e)
     {
         // handle
         throw; // <--- This is important, it rethrows the same exception while maintaining the stack trace.  This is *different* from "throw e"
     }
}
catch(AnotherException e)
{
    // handle 
}

Ответ 5

Это не плохая практика, если это оправдывает логика.

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

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

Ответ 6

Нет, это не обязательно плохая форма.

Точно так же, как и большинство этих типов вопросов (т.е. Is goto evil?, Is for (;;) evil?), эти вещи имеют свое место и подходят, если используются, когда они необходимы.

Ответ 7

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

Ответ 8

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

try
{

} 
catch (SqlException ex )
{
// Catches specific exception
}
catch ( Exception ex )
{
// Catch-all
}

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

try
{
   try
   {
   }
   catch ( Exception ex )
   {
   }
}
catch ( Exception ex )
{
}