Я поймал исключение!! Теперь, что?

Это зависит от вашей бизнес-логики, но вы можете выполнить одно или несколько из следующих действий.

• Откат транзакции
• Зарегистрируйте ошибку
• Предупредите любого пользователя приложения
• Повторите операцию
• Повторно вызовите исключение

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

Хорошая статья об обработке исключений VB.NET - это Обработка исключений в VB.NET Раджеша В.С.

К вашему сведению, вам не нужно использовать catch, чтобы иметь оператор finally.

Иногда люди генерируют новое исключение, которое более оперативно, и добавляют исходное исключение в качестве внутреннего исключения.

Часто это используется для записи ошибки в файл или отправки электронного письма оператору.

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

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

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

Если вы не хотите ничего с этим делать, вы всегда можете просто попробовать / finally, а не пытаться / catch / finally

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

catch (Exception ex)
{
  /* I don't know what to do.. *gulp!* */
}

Ясно, что это нехорошо, потому что происходят плохие вещи, и никаких действий не предпринимается. Поймать только те исключения, которые требуют действий!

При этом важна аккуратная обработка ошибок. Не хотите, чтобы ваше приложение вылетало, верно? Вы можете найти ELMAH полезным для веб-приложений, а глобальный обработчик исключений довольно легко настроить для настольных приложений WinForms или XAML.

Собрав все это вместе, вы можете найти эту стратегию полезной: 1. перехватить определенные исключения, которые, как вы знаете, могут произойти (DivideByZeroException, SQLException и т. Д.), И держаться подальше от универсального универсального исключения; 2. повторно вызовите исключение после его обработки. например

catch (SQLException ex)
{
  /* TODO: Log the error somewhere other than the database... */
  throw; // Rethrow while preserving the stack trace.
}

Что вы действительно можете делать с SQLException? Пропало соединение с базой данных? Это был плохой запрос? Вероятно, вы не захотите добавлять для этого всю логику обработки, и, кроме того, что, если вы этого не ожидали? Так что просто обработайте исключение, если можете, повторно вызовите его, если вы не уверены, что оно разрешено, и аккуратно обработайте его на глобальном уровне (например, Показать сообщение типа «Что-то пошло неверно, но вы можете продолжить работу. Подробная информация: '[ex.Message]'. Прервать или повторить? ")

HTH!

Джон Сондерс, спасибо за исправление.

Это зависит от того, что действительно делает SQL . Это что-то:

• сделал пользователь? Возможно, создайте учетную запись или сообщение - тогда вам нужно сообщить пользователю, что что-то не так
• , что приложение делает естественным образом? Например, очистить журналы или что-то подобное? Это смертельно? Может ли приложение продолжаться? Это что-то, что можно проигнорировать - возможно, повторить? Следует ли объявить администратора?

Начните с этих вопросов, обычно они приводят к ответам о том, как обрабатывать исключения

Я вижу много рекомендаций, чтобы не ловить это, если вы не знаете, что с этим делать. Это только вроде верно. Вы должны улавливать исключения, но, возможно, не на этом уровне. Используя ваш код в качестве примера, я бы написал это примерно так:

Using connection As New SqlConnection("connection string here"), _
      sqlCmd As New SqlCommand("do some SQL", connection), _
      sqlDa As New SqlDataAdapter(sqlCmd)

    sqlDa.Fill(dt)
End Using

Нет не только Try / Catch / Наконец, нет ни открытия, ни закрытия. Функция .Fill () задокументирована как открытие соединения при необходимости, а блок Using гарантирует, что оно правильно закрыто, , даже если генерируется исключение .

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

Фактически, именно способность исключений «всплывать» в вашем коде делает их такими ценными. Если вы всегда ловите исключение прямо там, где оно возникло, то исключения не добавляют особой ценности, кроме старого синтаксиса vb «On Error Goto X».

Следует иметь в виду, что в разделах, где, по вашему мнению, вы действительно хотите использовать a try / catch, вы должны переместить свои операторы Dim из блока try. Вы можете присвоить им значения внутри блока, но если вы определите их внутри блока try, у вас не будет доступа к этим переменным внутри секции catch, поскольку в этот момент они будут вне области видимости.

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

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

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

Если не знаете, как на это среагировать, не ловите исключение.

Вместо этого ловите его в том месте, где у вас есть возможность с ним справиться и где вы знаете, как продолжить выполнение впоследствии.

Что вы хотите сделать? Это полностью зависит от вашего приложения.

Вы можете повторить попытку, вы можете вывести на экран окно сообщения, записать в журнал - возможности безграничны.

Как разработчик, вы не можете предсказать все возможные ошибки. Хорошая идея - иметь общий код перехвата, даже если вы не знаете, как исправить ошибку. Вы можете сохранять данные в базе данных, и может произойти одна из 50 ошибок базы данных, и вы не сможете написать код для обработки каждой из них.

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

Вот почему я не согласен с комментарием о том, что не следует заниматься этим, если вы не знаете, что делать. Вы всегда должны обрабатывать это, даже если это просто отображение окна сообщения с сообщением «Ошибка», потому что это бесконечно лучше, чем «Эта программа выполнила недопустимую операцию и будет закрыта».

Это полностью зависит от контекста. Возможные варианты включают «Использовать данные по умолчанию вместо данных из базы данных» и «Отображать сообщение об ошибке для пользователя».

Если только вы не ожидали ошибки (API говорит, что она может возникнуть) и не можете ее обработать (есть очевидный шаг, который нужно предпринять, если возникнет исключение), вы, вероятно, захотите сбой с большим шумом . Это должно произойти во время тестирования / отладки, чтобы ошибку можно было исправить до того, как пользователь ее увидит!

Конечно, как отмечали комментаторы, пользователь никогда не должен действительно видеть весь этот шум . Высокоуровневый try / catch или какой-либо другой метод (EMLAH, я слышал для веб-проектов .net) можно использовать, чтобы показать пользователю красивое сообщение об ошибке («Ой! Что-то пошло не так! Что, черт возьми, вы пытались это сделать? ") с помощью кнопки отправки ...

Итак, в основном, моя точка зрения такова: Не обнаруживайте ошибок, которые вы не знаете, как обрабатывать! (кроме обработчика высокого уровня). Завершите работу заранее и предоставьте как можно больше информации. Это означает, что вы должны записать стек вызовов и другую важную информацию, если это вообще возможно для отладки.

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