Неправильно ли иметь оператор return в блоке catch?
Каковы альтернативы?
то есть:
public bool SomeFunction()
{
try
{
//somecode
return true;
}
catch(Exception ex)
{
MessageBox.Show(ex.message);
return false;
}
}
Вы можете нормально вернуться из блока catch. Обычно это хороший функциональный код.
Один из вариантов - сохранить возвращаемое значение во временной переменной:
public bool SomeFunction()
{
bool success = true;
try
{
//somecode
}
catch(Exception ex)
{
MessageBox.Show(ex.message);
success = false;
}
return success;
}
Но лично я нахожу то, как вы его написали (с одним catch-all catch statement), чтобы быть более читаемым. С другой стороны, если вы ожидаете конкретного исключения, и у вас может быть несколько путей для возврата успеха или нет...
try
{
DoTheImportantThing();
DoTheOtherThingThatMightFailButWeDontCare();
}
catch (DontCareAboutItException ex)
{
log.Info(ex);
}
catch (Exception ex)
{
log.Error(ex);
return false;
}
return true;
Тогда, на мой взгляд, вам лучше всего отталкивать операторы return как можно ближе к концу.
В качестве побочного примечания, в зависимости от приложения, рассмотрите регистрацию исключений, которые вы улавливаете, а не просто показываете их пользователю. Записанные исключения намного надежнее, чем пользовательский рассказ о том, что произошло.
Если в блоке try уже есть оператор return, я бы, вероятно, поместил бы другой результат в конце функции:
try
{
//somecode
return true;
}
catch(Exception ex)
{
MessageBox.Show(ex.message);
}
return false;
И это во избежание множественных возвратов, если нужно обрабатывать несколько исключений.
Это нормально, просто имейте в виду, что какой-то код может быть выполнен после команды возврата (возвращаемое значение будет обналичено).
try
{
return;
}
catch(Exception ex)
{
return;
}
finally
{
//some code
}
public bool SomeFunction()
{
try
{
//somecode
return true;
}
catch(Exception ex)
{
MessageBox.Show(ex.message);
}
return false;
}
Лично я помещаю оператор return в нижней части метода, а не в catch-block. Но оба прекрасны. Все это касается читаемости (субъективности) и рекомендаций в вашей организации.
Это не так, но если вы использовали ресурс, как правило, для его закрытия обычно используется блок, а не вызов метода close дважды. В этом случае вы можете использовать оператор return после блока finally.
Да, это совершенно нормально.
Не забывайте, что вы также можете использовать блок finally, который будет выполнен после возврата.
В общем, не делайте этого. Проблема заключается в том, что визуально и технически логика улова требует выхода из блока catch. Например, если у вас есть последний блок, как вы думаете, этот код вам даст?
int Test(out int t)
{
int i = 1;
t = 1;
try
{
if(DateTime.Now.Second < 58)
throw new Exception();
}
catch (Exception)
{
return i;
}
finally
{
i = 2;
t = 2;
}
return -1;
}
Ответ: он вернет 1, как если бы мы выполнили только я = 1, но он имел бы t = 2, хотя t = 2 произошло после я = 2.
Как вы видите, нарушено визуальное и техническое правило "без кода после возврата".
Создает для меня идеальный смысл для функции, которая возвращает true при успехе и false при неудаче. Надеюсь, в этом нет ничего плохого - я делаю это все время:)
Основная цель блока catch состоит в том, чтобы предоставить место, где можно выполнить исключительную ситуацию, которая произошла в блоке try. Итак, вы поймали исключение, продолжили его... и вернулись из метода. Если метод вызывающего пользователя не заботится об исключении, это абсолютно нормально.
Вы можете добавить return в блок catch. Вы явно знаете, что ваш код вернется и продолжит выполнение вместо остановки в блоке catch.
try{
//do something
}
catch{
//error handling
return;
}
Вместо того, чтобы иметь много блоков try-catch в вашем коде, которые могут запутаться и просто вызвать беспорядок в вашем коде, лучше обработать все, что вы пытаетесь поймать в noe, и просто проверить, что это за ошибка.
try{
//do something
}
catch (Exception as err){
if (err == "IOException"){
//handle exception
else if (err.indexOf("TypeError"){
//handle exception
}
}
Это два способа проверки типа исключения, чтобы вы могли отображать сообщение соответствующим образом. Вы также можете просто перехватить определенные исключения, если хотите, вместо Exception as err вы можете сделать catch IOException, ...