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

Question

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

Answer 1

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

TRY… CATCH конструкции не захватывают следующие условия:

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

Следующие типы ошибок не являются обрабатывается блоком CATCH, когда они происходят на том же уровне исполнения в качестве конструкции TRY… CATCH:

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

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

Answer 2

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

Например:

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

TAINSTABLE(table, *, @WordList)

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

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

Answer 3

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

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

Answer 4

Я работаю в SQL Server 2008. Я создал большой SQL-оператор с попыткой / уловом. Я проверил это, переименовав таблицу (в 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;

Answer 5

Я никогда не сталкивался с ситуацией, когда TRY ... CATCH ... не удался. Вероятно, у Neiteher есть много людей, которые читают этот вопрос. Это, увы, только означает, что если есть такая ошибка SQL, то мы ее не видели. Дело в том, что это довольно большое «если». Хотите верьте, хотите нет, но Microsoft прилагает некоторые усилия для того, чтобы сделать свои основные программные продукты довольно надежными, и TRY ... CATCH ... вряд ли является новой концепцией. Быстрый пример: в SQL 2005 я столкнулся с серьезной, наглядной и воспроизводимой ошибкой при разработке нового тогда разбиения таблицы - эта ошибка уже исправлена ​​патчем. И TRY ... CATCH ... используется немного чаще, чем разбиение таблиц.

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