Когда использовать и если не использовать Выгоду Попытки Наконец
Я создаю веб-приложения asp.net в .net 3.5, и я хотел знать, когда использовать и если не использовать Выгоду Попытки Наконец блоки? В частности, большинство моей выгоды попытки перенесены вокруг выполнения сохраненного procs и заполнения текстовых полей или gridviews? Вы использовали бы Выгоду Попытки КАЖДЫЙ РАЗ, когда Вы выполняете сохраненный proc и заполнили управление дисплеем данных?
Мой блок кода обычно похож:
protected void AddNewRecord()
{
try
{
//execute stored proc
// populate grid view controls or textboxes
}
catch (Exception ex)
{
//display a messagebox to user that an error has occured
//return
}
finally
{ }
}
7 ответов
Ответ - «это зависит от обстоятельств».
Возможно, вы захотите использовать try {...} catch {...} вокруг каждой атомарной операции, чтобы в случае возникновения проблемы вы могли вернуться к последнему исправному состоянию (используя транзакции ). Это может быть одна или несколько хранимых процедур - это зависит от вашего приложения.
Если вы перехватываете исключение, убедитесь, что вы явно указали, какие исключения вы перехватываете. У вас не должно быть catch (Exception ex) или catch () , известных как обработка исключений "перехватить все", но должны быть определенные операторы catch, такие как catch (IndexOutOfRangeException ex) (например) вместо этого.
Однако, если вы не можете обработать исключение или ничего не можете сделать, чтобы очистить его, вам не следует перехватывать его.
Вы должны использовать try catch, только если вы собираетесь обработать исключение в блоке catch. Под обработкой я подразумеваю запись ошибки в журнал, выбор другого пути из-за ошибки и т.д. Если вы собираетесь просто перебросить исключение, то нет смысла в try catch.
Как говорили другие, это зависит от обстоятельств. Я обычно использую блоки try / catch / finally в двух ситуациях:
Мне нужно обработать исключение другим способом, а не просто повторно выбросить его.
Мне нужно очистить некоторые ресурсы в блоке
finally.
Кроме этих двух ситуаций, я позволяю вызывающему коду обрабатывать любые исключения, которые могут произойти.
В дополнение к тому, что говорили другие, избегайте этого:
try
{
throw new ApplicationException("Fake sql ex");
}
//catch and do nothing. swallowing exceptions
catch(Exception){ }
Какое исключение вы ожидаете от сохраненной процедуры? Если вы не используете обработку исключений покемонов и точно знаете, что должно делать ваше приложение, все, что не соответствует конкретному исключению, которое вы хотите перехватить, будет перехвачено приложением объект.
Другими словами, не используйте catch {} или catch (Exception) , а используйте специализированную обработку исключений:
catch(SqlException e)
{
// Log stacktrace and show a friendly error to your user
}
Событие Application.Error именно здесь следует обнаруживать неожиданное поведение, и его легче отследить, чем просто попросить клиента вернуться к вам со словами «в моих полях ничего не отображается».
Используйте "try catch" внутри самого внутреннего цикла, который должен продолжать выполняться при возникновении определенного исключения. Имейте в виду, что если у вас есть цикл, который выполняется 10 000 раз, и исключение возникает, например, на десятом повторении, что не повлияет на остальные 9 990 повторений, может быть полезно поймать исключение и позволить циклу продолжить выполнение. С другой стороны, если исключение указывает на ошибку, которая предполагает, что 11-й, 12-й, 13-й и т.д. повторы цикла также будут неудачными, будет гораздо быстрее позволить исключению завершить цикл, чем продолжать повторять операцию, которая не сработает.
Большую часть времени вы не должны ловить исключения. В некоторых случаях имеет смысл ловить исключения, например,
Когда вы можете восстановить конкретное исключение. Когда вам нужно записать его в журнал или сообщить о нем (например, пользователю) - обычно на верхнем уровне вашего кода. Когда вызывающая сторона вашего кода не может обрабатывать исключения, поэтому вам нужно преобразовать их в другой формат ошибок.
Кроме того, оператор using block можно использовать для фактического вызова Dispose на объектах IDisposable, что устраняет необходимость в try...finally.