Является ли следующая неправильная практика кода?
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 попытки вложены прямо так, могут спросить, почему, но полностью ли это табу или принято сейчас на практике?
Спасибо, ребята, я согласен с вами по поводу рефакторинга, создав отдельный метод для вспомогательной функциональности, метод стал очень длинным. Я очень впечатлен всем, кто выбрал это...
Нет. Я не думаю, что это плохая практика.
Если вы делаете что-то в первой, вложенной попытке, которую вы можете поймать и обработать правильно, это прекрасно, особенно если вы "ловите" разные типы исключений в двух обработчиках.
Однако я бы сказал, что это потенциально хорошая возможность для рефакторинга и разделение вложенного раздела на отдельный метод. Часто, когда я это видел, это признак того, что метод следует разделить на более мелкие методы. Однако это не всегда так.
По-моему, этого не должно быть. Иногда вам нужен какой-то код в первой попытке выполнить, даже если код во втором случае не работает.
Можно также добавить, что другие люди правы в том, что они говорят. Я просто говорю, что это всегда должно быть плохо. В программе, не требующей производительности, вы можете просто сделать это, как вам нравится.
Это зависит от того, что должна делать ваша программа. Как правило, лучше всего обернуть try/catch вокруг наименьшей области работы и сосредоточить внимание на обработке исключений, насколько это возможно, чтобы избежать неожиданного поведения, побочных эффектов или ошибок. Много раз это будет означать наличие последовательности блоков try/catch, что отлично.
Я думаю, это зависит от того, как вы обрабатываете внутреннее исключение. Возможно, очень логично, что ваш внутренний улов должен делать что-то совершенно иное, чем попадание в область внешнего улова. Единственное, чего вы хотели бы избежать, - это скрывать внутреннее исключение как причину внешнего исключения. Другими словами, я настоятельно рекомендую
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
}
Это не плохая практика, если это оправдывает логика.
Например, если внешний try для catch исключения SQL, а самый внутренний try для исключения IO, возможно, было бы разумно сделать это.
Тем не менее, будьте осторожны, чтобы избежать наличия предложений try-all try, которые охватывают большое количество строк кода. Это не хорошая практика.
Нет, это не обязательно плохая форма.
Точно так же, как и большинство этих типов вопросов (т.е. Is goto evil?, Is for (;;) evil?), эти вещи имеют свое место и подходят, если используются, когда они необходимы.
Если есть исключение, которое вы можете обрабатывать внутри первого блока try и продолжать успешно, я не думаю, что с ним возникнут проблемы. Если это просто сделать что-то и повторно бросить, просто добавьте еще один блок catch для определенного типа исключения, которое вы ищете, и обрабатывайте его там.
Это не страшно, однако посмотрите, не можете ли вы просто решить это, обратившись к типам исключений, если это необходимо:
try
{
}
catch (SqlException ex )
{
// Catches specific exception
}
catch ( Exception ex )
{
// Catch-all
}
Каждый раз, когда вы делаете попытку, вы создаете еще один поток утверждений, который обходит читабельность. Например:.
try
{
try
{
}
catch ( Exception ex )
{
}
}
catch ( Exception ex )
{
}