We may have two basic types of pattern:

• The new one using THROW keyword
• The legacy one with RAISERROR()

THROW version:

BEGIN TRY
    BEGIN TRAN

		PRINT 1/0 -- "Divide by zero error encountered." error

END TRY
BEGIN CATCH

    IF @@TRANCOUNT > 0
        ROLLBACK TRANSACTION

	;THROW

END CATCH

IF @@TRANCOUNT > 0
	ROLLBACK
GO

RASIERROR() version:

BEGIN TRY

    BEGIN TRAN

		PRINT 1/0 -- "Divide by zero error encountered." error

END TRY
BEGIN CATCH

    IF @@TRANCOUNT > 0
        ROLLBACK TRANSACTION

	DECLARE @Message NVARCHAR(4000)

	SET @Message = ERROR_MESSAGE()

    RAISERROR (@Message, 16, 1);

END CATCH

IF @@TRANCOUNT > 0
	ROLLBACK
GO

They both work pretty well for most of the usage scenarios but there is one very important difference to remember: The THROW statement is terminating the batch where it fires an error!

Let’s see it in action:

BEGIN TRY
    BEGIN TRAN

		PRINT 1/0 -- "Divide by zero error encountered." error

END TRY
BEGIN CATCH

    IF @@TRANCOUNT > 0
        ROLLBACK TRANSACTION

	;THROW

	SELECT 'This Wan''t be executed 1'

END CATCH

SELECT 'This Wan''t be executed 2'
GO

Once the THROW statement was executed it has also terminated the batch and SELECT statements weren’t executed. If we will run the same with RAISERROR() the result is different:

BEGIN TRY

    BEGIN TRAN

		PRINT 1/0
	
END TRY
BEGIN CATCH

	DECLARE @Message NVARCHAR(4000)
	SET @Message = ERROR_MESSAGE()

	RAISERROR(@Message, 16, 1);
	
	SELECT 'This is executed 1'	

END CATCH

SELECT 'This is executed 1'	
GO

Same time the error message will be fired in the Messages window.

This is a very important difference that can drastically affect more complex T-SQL logic especially in the case of nested stored procedures or retry logic patterns.

For more details see:

• THROW
• RAISERROR()

Even if it looks to be easy, using TRY … CATCH is very complex when the type of fired error or other conditions came in the game. The best article ever written on this topic is by Erland Sommarskog. I’m strongly recommending read it thru.

Jednou z elegantních možností je, že pro sestavení chybové zprávy vytvoříme samostatnou proceduru, kterou budeme následně volat z CATCH bloku bez dalšího zbytečného kódu.

Procedura pro sestavení chybové zprávy může vypadat například takto:

CREATE OR ALTER PROCEDURE [dbo].[FireError]
AS
BEGIN    
    
	DECLARE @ErrorMessage NVARCHAR(MAX)
	DECLARE @ErrorSeverity INT
	DECLARE @ErrorState INT

	SET @ErrorSeverity = ERROR_SEVERITY()
	SET @ErrorState = ERROR_STATE()

    SET @ErrorMessage =  
        '|' + ISNULL(CAST(ERROR_NUMBER() AS NVARCHAR(10)), 'ERROR_NUMBER') +  ' | ' +
              ISNULL(CAST(@ErrorSeverity AS NVARCHAR(10)), 'ERROR_SEVERITY') +  ' | ' +
              ISNULL(CAST(@ErrorState AS NVARCHAR(10)), 'ERROR_STATE') +  ' | ' +
              ISNULL(ERROR_PROCEDURE(), 'CALLED_OUTSIDE_STORED_PROCEDURE') +  ' | ' +
              ISNULL(CAST(ERROR_LINE() AS NVARCHAR(10)), 'ERROR_LINE') +  ' | ' +
              ISNULL(ERROR_MESSAGE(), 'ERROR_MESSAGE')  + 
        '|'
    
	RAISERROR(@ErrorMessage, @ErrorSeverity, @ErrorState)

	RETURN 0

END
GO

Tělo procedury pouze volá systémové funkce pro získání popisu chyby a formátuje jejich výstup do uživatelský přívětivé podoby.

Proceduru pak můžeme volat v CATCH bloku takto:

BEGIN TRY

	PRINT 1/0

END TRY
BEGIN CATCH

	EXEC [dbo].[FireError]

END CATCH
GO

Na obrázku je vidět, jak vypadá zformátovaná chybová zpráva. A barevně je vyznačeno jedno drobné vylepšení, které jsme do sestavení chybové zprávy přidali: pokud již nastane v SQL Serveru uživatelská chyba, často první po čem budeme pátrat je, zda se jednalo o ad-hoc kód nebo došlo k chybě v uložené proceduře. Zde vidíme, že k chybě došlo v kódu mimo uloženou proceduru.

Pojďme nyní otestovat stejnou chybu, ale vyvolejme ji v těle testovací uložené procedury:

CREATE PROCEDURE [dbo].[TestProcedure]
AS
BEGIN

	BEGIN TRY

		PRINT 1/0

	END TRY
	BEGIN CATCH

		EXEC [dbo].[FireError]
	
	END CATCH
    
END
GO

EXEC [dbo].[TestProcedure]
GO

Nyní nám chybová zpráva přímo ukazuje název uložené procedury, ve které k chybě došlo a vím tak rovnou, kam do databáze sáhnout a chybu opravit.