Когда использовать и когда не использовать Try Catch Наконец

Я создаю веб-приложения asp.net в .net 3.5, и я хотел знать, когда использовать и когда не использовать Try Catch finally? В частности, большинство моих попыток захвата завернуты в выполнение хранимых процессов и заполнение текстовых полей или gridviews? Не могли бы вы использовать Try Catch EVERYTIME, когда вы выполняете хранимый процесс и заполняете элемент управления отображением данных?

Мой кодовый блок обычно выглядит так:

    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
        { }
   }

ОТВЕТЫ

Ответ 1

Ответ: "Это зависит".

Возможно, вы захотите использовать try{...} catch {...} вокруг каждой атомной операции, так что если есть проблема, вы можете вернуться к последнему хорошему состоянию (используя транзакции). Это может быть одна или несколько хранимых процедур - это зависит от вашего приложения.

Если вы задерживаете исключение, убедитесь, что вы явно, в каких исключениях вы поймаете. У вас не должно быть catch (Exception ex) или catch() - известно как обработка исключений "catch all", но вместо этого есть определенные инструкции catch, например catch (IndexOutOfRangeException ex) (например).

Однако, если вы не можете обработать исключение, или вы ничего не можете сделать для очистки, тогда вы не должны его ловить.

Ответ 2

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

Ответ 3

Как говорили другие, это зависит. Я стараюсь использовать блоки try/catch/finally в двух ситуациях:

  • Мне нужно обработать исключение каким-то другим способом, кроме как просто перебросить его.

  • Мне нужно очистить некоторые ресурсы в блоке finally.

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

Ответ 4

В дополнение к тому, что говорили другие, обязательно избегайте этого:

    try
    {
        throw new ApplicationException("Fake sql ex");
    }
    //catch and do nothing.  swallowing exceptions
    catch(Exception){ }

Ответ 5

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

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

Кроме того, оператор использования блока может использоваться для фактического вызова Dispose на объекты IDisposable, что устраняет необходимость в попытке... наконец.

Ответ 6

Что такое Exception, которое вы ожидаете от хранимой процедуры? Если вы не используете обработку исключений pokemon и точно знаете, что должно делать ваше приложение, все, что не подходит для конкретного исключения, которое вы хотите поймать, будет пойманный объектом Application.

Другими словами, не используйте catch {} или catch (Exception), а специализированную обработку исключений:

catch(SqlException e)
{
   // Log stacktrace and show a friendly error to your user
}

Событие Application.Error - это то, где неожиданное поведение следует поймать и его легче отслеживать, чем просто возврат клиента к вам, говорящий "мои поля ничего не отображают".

Ответ 7

Используйте "try catch" внутри самого внутреннего цикла, который должен продолжать выполнение, когда возникает конкретное исключение. Помните, что если у вас есть цикл, который выполняет 10000 раз, и возникает исключение, например. десятое повторение, которое не повлияет на другие 9,990, может быть полезно поймать исключение и позволить циклу продолжать движение. С другой стороны, если исключение указывает на ошибку, которая говорит о том, что 11-й, 12-й, 13-й и т.д. Времена через цикл также будут терпеть неудачу, было бы намного быстрее разрешить исключение в цикле, чем продолжать повторную операцию это не сработает.