What is wrong with my Try Catch in T-SQL?

Question

I am using SQL Server 2008 and when I run this Statement in Management studio the Select statement in the Catch Block is executed as expected

BEGIN TRY
 INSE         


        

Answer 1

I don't get the CATCH block hit at all.

That's because the code won't compile, because the object doesn't exist, no plan is generated, so nothing runs to hit the CATCH block.

You can never hit this catch block so somethign is wrong with your testing/example. You can hit an outer catch block in a different scope (eg nested stored procs)

Edit: I'm using SQL Server 2005 SP3

It depends when deferred name resolution applies, related to statement level recompilation.

• In my case, the whole batch fails both times and no statement level recompilation happens so no deferred name resolution

• In OP's case, the batch compiles and runs but then has a statement level recompilation/deferred name resolution error in running code

I'm off to find some references about why it's different, given BOL doesn't say much, neither does Erland Sommarskog

Answer 2

Now that we have all the explanations as to why this is happening. Let's see an actual solution to the problem.

First let's take the statements that @d-k-mulligan proposed above and turn them into stored procs.

IF OBJECT_ID('dbo.prcIDontExistINSERT', 'P') IS NOT NULL DROP PROCEDURE dbo.prcIDontExistINSERT
GO
CREATE PROCEDURE dbo.prcIDontExistINSERT 
AS
BEGIN TRY
 INSERT INTO IDontExist(ProductID)
 VALUES(1)
END TRY
BEGIN CATCH
  SELECT 'There was an error! ' + ERROR_MESSAGE()
END CATCH
GO

IF OBJECT_ID('dbo.prcIDontExistSELECT', 'P') IS NOT NULL DROP PROCEDURE dbo.prcIDontExistSELECT
GO
CREATE PROCEDURE dbo.prcIDontExistSELECT 
AS
BEGIN TRY
  SELECT * FROM IDontExist
END TRY
BEGIN CATCH
  SELECT 'There was an error! ' + ERROR_MESSAGE()
END CATCH
GO

If we run either of them we see the same error.

EXEC dbo.prcIDontExistINSERT
EXEC dbo.prcIDontExistSELECT

Msg 208, Level 16, State 1, Procedure prcIDontExistSELECT, Line 4
Invalid object name 'IDontExist'.

The solution now is to create error handling wrapper procs with the sole purpose of catching any error from the original procs above that are getting the object not found errors.

IF OBJECT_ID('dbo.prcIDontExistInsert_ERROR_HANDLER', 'P') IS NOT NULL DROP PROCEDURE dbo.prcIDontExistInsert_ERROR_HANDLER
GO
CREATE PROCEDURE dbo.prcIDontExistInsert_ERROR_HANDLER 
AS
BEGIN TRY
 EXEC dbo.prcIDontExistINSERT
END TRY
BEGIN CATCH
  SELECT 'There was an error! ' + ERROR_MESSAGE()
END CATCH
GO

IF OBJECT_ID('dbo.prcIDontExistSELECT_ERROR_HANDLER', 'P') IS NOT NULL DROP PROCEDURE dbo.prcIDontExistSELECT_ERROR_HANDLER
GO
CREATE PROCEDURE dbo.prcIDontExistSELECT_ERROR_HANDLER 
AS
BEGIN TRY
 EXEC dbo.prcIDontExistSELECT
END TRY
BEGIN CATCH
  SELECT 'There was an error! ' + ERROR_MESSAGE()
END CATCH
GO

Finally, let's run either of our error handling procs and see the message we expect.

EXEC dbo.prcIDontExistInsert_ERROR_HANDLER
EXEC dbo.prcIDontExistSELECT_ERROR_HANDLER

There was an error! Invalid object name 'IDontExist'.

NOTE: Kalman Toth did all the hard research work here: http://www.sqlusa.com/articles2008/trycatch/

Answer 3

Directly from http://msdn.microsoft.com/en-us/library/ms175976.aspx.

USE AdventureWorks2008R2;
GO

BEGIN TRY
    -- Table does not exist; object name resolution
    -- error not caught.
    SELECT * FROM NonexistentTable;
END TRY
BEGIN CATCH
    SELECT 
        ERROR_NUMBER() AS ErrorNumber
        ,ERROR_MESSAGE() AS ErrorMessage;
END CATCH

The error is not caught and control passes out of the TRY…CATCH construct to the next higher level.

Running the SELECT statement inside a stored procedure will cause the error to occur at a level lower than the TRY block. The error will be handled by the TRY…CATCH construct.

Answer 4

Workaround with dynamic sql. Maybe it will be helpful for someone.

begin try
    exec('
        insert into IDontExist(ProductID)
        values(1)
    ')
end try
begin catch
    select 'There was an error! ' + error_message()
end catch

Answer 5

This behaviour happens if you previously had a table IDontExist and compiled a plan for it that is still in the cache then drop the table.

It also happens if you run the individual statement twice even without the table ever existing. The first run raises an error that is not caught. The second run (after the first plan is cached) succeeds.

/*Clear Cache*/
DBCC FREEPROCCACHE

GO

BEGIN TRY
 INSERT INTO IDontExist(ProductID)
 VALUES(1)
END TRY
BEGIN CATCH
SELECT 'There was an error! ' + ERROR_MESSAGE()
END CATCH

GO
/*Plan now Cached*/

SELECT query_plan
FROM   sys.dm_exec_cached_plans cp
       OUTER APPLY sys.dm_exec_sql_text(plan_handle) t
       OUTER APPLY sys.dm_exec_query_plan(plan_handle) qp
WHERE  t.text LIKE '%IDontExist%'
OPTION (RECOMPILE)

GO

BEGIN TRY
 INSERT INTO IDontExist(ProductID)
 VALUES(1)
END TRY
BEGIN CATCH
SELECT 'There was an error! ' + ERROR_MESSAGE()
END CATCH

GO

The INSERT statement gets auto parameterised.

If you change your Select * from IDontExist statement to Select * from IDontExist WHERE ProductID = 1 this also becomes auto parameterised and they behave the same.

I'm not absolutely certain why the auto parameterisation makes a difference here. I think that it is explained by the below extract from BOL however.

The following types of errors are not handled by a CATCH block when they occur at the same level of execution as the TRY…CATCH construct ... [those] that occur during statement-level recompilation ... If an error occurs during compilation or statement-level recompilation at a lower execution level (for example, when executing sp_executesql or a user-defined stored procedure) inside the TRY block, the error occurs at a lower level than the TRY…CATCH construct and will be handled by the associated CATCH block.

I presume the auto parametrization of that statement means that it gets recompiled at a lower execution level and is catchable.

Answer 6

This has bitten me in the past as well.

Not all errors generated inside the TRY block statements are passed into the CATCH block. Any errors with a severity of 10 or less are considered to be warnings and do not cause control to flow to the CATCH block. Also, any errors that break the database connection will not cause the CATCH block to be reached. There may be other situations as well.