Я начал использовать блоки try-catch (немного поздно, я знаю!), Но теперь я не уверен, что делать с исключением, как только я его поймаю. Что мне делать?
Try
connection.Open()
Dim sqlCmd As New SqlCommand("do some SQL", connection)
Dim sqlDa As New SqlDataAdapter(sqlCmd)
sqlDa.Fill(dt)
Catch ex As SQLException
' Ahhhh, what to do now!!!?
Finally
connection.Close()
End Try
Практическое правило для обработки исключений - если вы не знаете, что с этим делать, не улавливайте его.
Следствие эмпирического правила обработки исключений - обрабатывать исключения в последний ответственный момент. Если вы не знаете, последний ли это ответственный момент, это не так.
Что ты хочешь делать? Это полностью зависит от вашего приложения.
Вы можете повторить попытку, вы можете отобразить окно сообщения на экране, записать в журнал, возможности безграничны.
Как разработчик, вы не можете предсказать каждую возможную ошибку. Было бы неплохо иметь общий код перехвата, даже если вы не знаете, как исправить ошибку. Возможно, вы сохраняете в базу данных, и может произойти одна из 50 ошибок в базе данных, и вы не сможете написать код для обработки каждой из них.
Вы должны добавить общий перехват, чтобы убедиться, что ваша программа не просто аварийно завершает работу, а в некоторых случаях достаточно просто отобразить ошибку и дать ей еще один шанс. Представьте себе, если причина была "диск заполнен". Вы можете просто распечатать исключение и позволить пользователю повторить попытку - он будет знать, что делать, и решит проблему самостоятельно.
Вот почему я не согласен с комментарием о том, чтобы не обрабатывать его, если вы не знаете, что делать. Вы должны всегда обрабатывать это, даже если это просто для отображения окна сообщения с сообщением "Ошибка", потому что оно бесконечно лучше, чем "Эта программа выполнила недопустимую операцию и будет закрыта".
Это зависит от вашей бизнес-логики, но вы можете сделать одно или несколько из следующих.
Вы также можете проверить, является ли исключение типом, который вы можете обрабатывать, до одного из указанных выше.
Хорошая статья об обработке исключений VB.NET - Обработка исключений в VB.NET от Rajesh VS.
Я вижу много рекомендаций не ловить это, если вы не знаете, что с этим делать. Это единственное право. Вы должны ловить исключения, но, возможно, не на этом уровне. Используя ваш код в качестве примера, я бы написал так:
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".
Это зависит от того, что на самом деле делает SQL. Это что-то:
Начните с этих вопросов, они обычно приводят к ответам о том, как обрабатывать исключения
Если вы не ожидали ошибки (API говорит, что это может произойти) и может справиться с ней (есть очевидный шаг, если возникает исключение), вы, вероятно, захотите сбой с большим количеством шума. Это должно произойти во время тестирования/отладки, так что ошибка может быть исправлена до того, как пользователь ее увидит!
Конечно, как отмечают комментаторы, пользователь никогда не должен действительно видеть весь этот шум. Высокоуровневый try/catch или какой-либо другой метод (EMLAH, я слышу для веб-проектов .net) можно использовать, чтобы показать пользователю хорошее сообщение об ошибке ( "Ой, что-то пошло не так! Что вы пытались сделать?" ) с кнопкой отправки...
В основном, я хочу сказать следующее: Не ловить ошибки, о которых вы не знаете, как обращаться! (за исключением обработчика высокого уровня). Крах рано и с максимальной информацией. Это означает, что вы должны зарегистрировать стек вызовов и другую важную информацию, если это вообще возможно для отладки.
Если вы не знаете, как реагировать на него, не поймайте исключение.
Поймайте его вместо этого в том месте, где у вас есть возможность обработать его, и где вы знаете, как продолжить выполнение впоследствии.
Следует иметь в виду, что в тех разделах, где вы чувствуете, что хотите использовать try/catch, вы должны перенести свои инструкции Dim из блока try. Вы можете назначить им значения внутри блока, но если вы определите их внутри блока try, у вас не будет доступа к этим переменным внутри секции catch, поскольку они будут недоступны в этой точке.
Моя стандартная практика в блоках catch, включая попытку исправления ошибки, если это возможно, заключается в том, чтобы выписать какой-либо механизм ведения журнала, я использую информацию о ключевых переменных, которые были вовлечены в раздел, вызывающий ошибку. Это не нужно, но я нашел, что это часто помогает при проблемах отладки.
Я хотел бы предложить вам, что, если вы не знаете, что делать с исключением, не поймайте его. Слишком часто кодеры ловят исключения и просто проглатывают их целиком.
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] '. Прервать или повторить? ")
НТН!
Джон Сондерс, спасибо за исправление.
Во-первых, если для приложения не существует способа обработать исключение, вы не должны его ловить (ведение журнала может выполняться с помощью обработчиков событий исключения без catch).
Если есть что-то, что вы можете сделать, сделайте это. Например, отмените транзакцию и сообщите об этом пользователю. Это будет зависеть от вашего приложения.
FYI, вам не нужно использовать catch для утверждения finally.
Иногда люди генерируют новое исключение, которое более firendly и добавляет исходное исключение в качестве внутреннего исключения.
Часто это используется для регистрации ошибки в файле или отправки электронной почты оператору.
Иногда, особенно с SQL, это может означать только дублирующий ключ, что означает, например, что вы выбираете другое имя пользователя, которое уже принято - все это относится к вашему приложению.
Я бы подумал о регистрации, что произошло исключение, и уведомить пользователя о том, что вы не смогли выполнить свой запрос. Это предполагает, что этот запрос SQL необходим для завершения действия, которое пользователь пытается выполнить.
Все зависит от контекста. Возможные варианты: "Использовать данные по умолчанию вместо данных из базы данных" и "Отобразить сообщение об ошибке для пользователя".
Если вы не хотите ничего с этим делать, вы всегда можете просто попробовать/наконец, а затем попробовать/уловить/наконец
В зависимости от типа приложения рассмотрите либо глобальный обработчик ведения журнала (т.е. "Application_Error" для приложений ASP.NET), либо используя предварительно построенный механизм обработки исключений с открытым исходным кодом или MSFT.
Блок приложений для обработки исключений как часть Enterprise Library 5.0 - предлагаемая структура для использования.
Помимо регистрации, я согласен с тем, что исключения не должны быть явно пойманы, если вам не нужно что-то делать с ними. И худшая ошибка - это просто "Поймать", а затем "Бросить", так как это помешает StackTrace.
Ну, Это зависит в первую очередь, если вы делаете деньги из своей заявки или нет. По моему опыту, никто (кто заплатил за заявку) любит видеть, как он рушится и закрывается, вместо этого они предпочитают короткое и объяснительное сообщение об ошибке и второй шанс продолжить то, что они делают, плюс возможность сохранить/экспортировать измененные данные. ИМО - лучшая практика - поймать все, что может вызвать что-то неправильное из-под вашего контроля, например операции ввода-вывода, связанные с сетью задачи, e.t.c. и отобразить соответствующее сообщение пользователю. В случае, если исключение выбрано из-за ошибки, связанной с логикой, лучше не улавливать ее, поскольку это поможет вам найти и исправить фактическую ошибку.
Надеюсь, что это поможет.