Проблемы с T-SQL TRY CATCH?

в настоящее время мы работаем над SQL 2005, и я переношу старую систему Foxpro на новое веб-приложение, поддерживаемое SQL Server. Я использую TRY CATCH в T-SQL для обработки транзакций, и, похоже, он работает очень хорошо. Один из других программистов на работе беспокоился об этом, поскольку он сказал, что слышал о проблемах, когда фраза catch не всегда ловила ошибку. Я избил sproc до смерти и не могу заставить его потерпеть неудачу (пропустить улов) , и единственные проблемы, которые я нашел в поиске вокруг сети заключается в том, что он не вернет правильный номер ошибки для номеров ошибок

13
sql-server try-catch tsql

5 ответов

TRY ... CATCH не ловит все возможные ошибки, но те, которые не пойманы, хорошо документированы в BOL ошибки, не затронутые конструкцией TRY ... CATCH

TRY...CATCH конструкции не ловят следующие условия:

  • предупреждения или информационные сообщения, имеющие серьезность 10 или ниже.
  • ошибки, имеющие серьезность 20 или выше, которые останавливают SQL Server Обработка задачи компонента Database Engine для сессия. Если возникает ошибка, что и тяжести 20 или выше, а соединение с базой данных не прерывается, Попробуйте ... CATCH обработает ошибку.
  • внимания, как запросы клиент-прерывания или сломленный клиентское подключение.
  • когда сеанс завершается системным администратором с помощью KILL заявление.

следующие типы ошибок не обрабатывается блоком CATCH, когда они происходят на одном уровне выполнения как попробовать ... поймать конструкция:

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

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

21

был один случай в моем опыте, когда попробуйте...Блок catch не перехватывает ошибку. Была связана ошибка с сортировки: Не удается разрешить конфликт параметров сортировки между "Latin1_General_CI_AS" и "Latin1_General_CI_AI" в равно операции. Возможно, эта ошибка соответствует одному из типов ошибок, описанных в BOL.

ошибки, возникающие при перекомпиляции на уровне оператора, например object ошибки разрешения имен, возникающие после компиляции из-за отложенное разрешение имен.

1

TRY ... CATCH не сможет поймать ошибку, если вы передадите" плохой " поисковый запрос в CONTAINSTABLE

например:

DECLARE @WordList VARCHAR(800)
SET @WordList = 'crap"s'
CON

TAINSTABLE(table, *, @WordList)

на CONTAINSTABLE даст вам "синтаксическую ошибку" и любые окружающие TRY ... CATCH не поймать.

это особенно неприятно, потому что ошибка вызвана данными, а не "реальной" синтаксической ошибкой в вашем коде.

1

Я работаю в SQL Server 2008. Я построил большой оператор sql, который имел try / catch. Я протестировал его, переименовав таблицу (в dev). Заявление взорвалось и не уловило ошибки. Try / catch в SQL Server слаб, но лучше, чем ничего. Вот часть моего кода. Я не могу больше вкладывать из-за ограничений моей компании.

    COMMIT TRAN T1;
END TRY
BEGIN CATCH
    -- Save the error.
    SET @ErrorNumber = ERROR_NUMBER();
    SET @ErrorMessage = ERROR_MESSAGE();
    SET @ErrorLine = ERROR_LINE();
    -- Put GSR.dbo.BlahBlahTable back the way it was.
    ROLLBACK TRAN T1;   
END CATCH
-- Output a possible error message. Knowing what line the error happened at really helps with debugging.
SELECT @ErrorNumber as ErrorNumber,@ErrorMessage as ErrorMessage,@ErrorLine AS LineNumber;
0

Я никогда не попадал в ситуацию, когда попробуйте...ПОЙМАТЬ... неудачный. Ни у кого, наверное, есть много людей, которые читают этот вопрос. Это, увы, означает только то, что если есть такая ошибка SQL, то мы ее не видели. Дело в том, что это довольно большое "если". Верьте или нет, Microsoft прилагает некоторые усилия, чтобы сделать свои основные программные продукты довольно прочными, и попробуйте...ПОЙМАТЬ... вряд ли это новая концепция. Быстрый пример: в SQL 2005 я столкнулся с твердой, наглядной и воспроизводимой ошибкой, в то время как разработка затем - новое разделение таблицы-какая ошибка, которая уже была исправлена патчем. И попробуй...ПОЙМАТЬ... используется немного чаще, чем секционирование таблиц.

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

-1