How to get inner errors from try/catch clause in SQL Server

Question

I am running a stored procedure in SQL Server 2008 inside a try/catch. The stored procedure and the stored procs it calls raise a few errors but in the try/catch you only get the last error from the stored procedure that you are running.

Is there a way/trick to be able to somehow catch ALL the errors generated by child stored proc calls while running a particular stored procedure? (assume that you have no access to any stored procedures so you can't modify where they can write the error, ie you can't just change all the stored procedures to stop raising errors and instead write them to some table and in your catch read from that table)

Answer 1

Here is a good resource for how to deal with error handling in SQL Server. http://www.sqlservercentral.com/articles/Development/anerrorhandlingtemplatefor2005/2295/

However, some of the methods require that you have the ability to change the code in order to capture the errors. There is really no way of getting around this. You can't just ignore the error, keep processing, and then come around later to deal with the error. In most, if not all, languages, exceptions have to be dealt with at the time the exception was raised. T-SQL is no different.

I personally use a stored procedure to log any error whenever it occurs. Here is what I use:

CREATE PROCEDURE [dbo].[Error_Handler]
@returnMessage bit = 'False'
WITH EXEC AS CALLER
AS
BEGIN

  INSERT INTO Errors (Number,Severity,State,[Procedure],Line,[Message])
  VALUES (
    ERROR_NUMBER(),
    ERROR_SEVERITY(),
    ERROR_STATE(),
    isnull(ERROR_PROCEDURE(),'Ad-Hoc Query'),
    isnull(ERROR_LINE(),0),
    ERROR_MESSAGE())

  IF(@returnMessage = 'True')
  BEGIN
    select Number,Severity,State,[Procedure],Line,[Message]
    from Errors
    where ErrorID = scope_identity()
  END
END

Answer 2

If you have stored procs that are raising more than one error, they need to be replaced no matter what. You probably have data integrity errors in your database. That is a critical, "everything needs to stop right now until this is fixed" kind of issue. If you can't replace them and they were incorrectly written to allow processing to continue when an error was reached, then I know of no way to find the errors. Errors are not recorded unless you tell them to be recorded. If the stored procs belong to a product you bought from another vendor and that's why you can't change them, your best bet is to change to a vendor that actually understands how to program database code because there is no salvaging a product written that badly.

Answer 3

You wouldn't have a Java or c# methods raising error after error. Why do you expect SQL to allow this? An exception is an exception

If the DB Engine is throwing errors then you have problems.

What I've done before is to separate testing and checking code: find out what is wronf first and throw one exception If no errors, do your writes.