@@ ОШИБКА и/или ПОПЫТКА - ВЫГОДА

Try Catch не перехватит все

вот код, демонстрирующий, что

    BEGIN TRY
      BEGIN TRANSACTION TranA
     DECLARE  @cond INT;
     SET @cond =  'A';
    END TRY
    BEGIN CATCH
     PRINT 'a'
    END CATCH;
    COMMIT TRAN TranA

Сервер: Msg 3930, уровень 16, состояние 1, строка 9 Текущая транзакция не может быть зафиксирована и не может поддерживать операции записи в файл журнала. Откатить транзакцию. Сервер: Msg 3998, уровень 16, состояние 1, строка 1 Незавершенная транзакция обнаруживается в конце пакета. Выполнен откат транзакции.

По моему опыту, согласно электронной документации блоки TRY ... CATCH будут перехватывать все события, которые могут вызвать ошибки (и, таким образом, установить @@ ERROR на ненулевое значение ценность). Я не могу придумать ни одного обстоятельства, при котором это не применимо. Так что нет, возвращаемое значение никогда не будет равно 1111, и было бы нецелесообразно включать эту проверку ошибок @@.

Однако обработка ошибок может быть очень критичной, и я бы хеджировал свои ставки на такие крайние ситуации, как как DTC, связанные серверы, службы уведомлений или брокерские услуги, а также другие функции SQL, с которыми я имел очень мало опыта. Если можете, проверьте свои более причудливые ситуации, чтобы увидеть, что на самом деле произойдет.

The whole point of "Try..Catch" is so that you don't have to check for @@ERROR for every statement.

So it's not worthwhile.

TRY / CATCH перехватывает больше. Это намного и удивительно лучше.

DECLARE @foo int

SET @foo = 'bob' --batch aborting pre-SQL 2005
SELECT @@ERROR
GO
SELECT @@ERROR  --detects 245. But not much use, really if the batch was a stored proc
GO


DECLARE @foo int
BEGIN TRY
    SET @foo = 'bob'
    SELECT @@ERROR
END TRY
BEGIN CATCH
    SELECT ERROR_MESSAGE(), ERROR_NUMBER()
END CATCH
GO

Использование TRY / CATCH в триггерах также работает. Откат триггера раньше тоже был пакетным прерыванием: больше не будет, если TRY / CATCH также используется в триггере.

Ваш пример будет лучше, если BEGIN / ROLLBACK / COMMIT находится внутри, а не снаружи конструкции

Я не верю, что управление когда-либо достигнет оператора RETURN - как только вы находитесь в блоке TRY, любая возникшая ошибка передаст управление блоку CATCH. Однако есть некоторые очень серьезные ошибки, которые могут привести к прерыванию пакета или даже самого соединения (Эрланд Соммарског написал на тему ошибок в SQL Server здесь и здесь - к сожалению, он не обновил их, чтобы включить TRY ... CATCH). Я не уверен, что вы сможете ПОЛУЧИТЬ подобные ошибки, но тогда @@ ERROR тоже не годится.