Exception vs run-time error.

Question

In C# there is no any difference between the folowing two lines of code:
int d = 0; int i = 1/d;
throw new DivideByZeroException();
However, in T-SQL world, it seems that the following two lines are not the same:
SELECT 1/0;
RAISERROR ('Divide by zero error encountered.', 16, 1);
even though they generate similar messages:
Msg 8134, Level 16, State 1, Line 1
Divide by zero error encountered.
Msg 50000, Level 16, State 1, Line 1
Divide by zero error encountered.
Extract from
MSDN:
RAISERROR Generates an error message and initiates error processing for the session.
Another
extract:
SET XACT_ABORT Specifies whether SQL Server automatically rolls back the current transaction when a Transact-SQL statement raises a run-time error.
When I run the following two SPs, I get different behaviour:
CREATE PROCEDURE dbo.USP_PROCEDURE_1
AS
BEGIN
SET XACT_ABORT, NOCOUNT ON;
BEGIN TRAN;
select 1/0;
PRINT 'I did not reach that point.'
END
GO
CREATE PROCEDURE dbo.USP_PROCEDURE_2
AS
BEGIN
SET XACT_ABORT, NOCOUNT ON;
BEGIN TRAN;
RAISERROR ('Divide by zero error encountered.', 16, 1);
PRINT 'Why did I reach that point?'
END
GO
The first SP rollbacks transaction and returns the following message:
Msg 8134, Level 16, State 1, Procedure USP_PROCEDURE_1, Line 7
Divide by zero error encountered.
The second SP leaves transaction open:
Msg 50000, Level 16, State 1, Procedure USP_PROCEDURE_2, Line 7
Divide by zero error encountered.
Why did I reach that point?
Msg 266, Level 16, State 2, Procedure USP_PROCEDURE_2, Line 0
Transaction count after EXECUTE indicates a mismatching number of BEGIN and COMMIT statements. Previous count = 0, current count = 1.
Is it by design? Why? What is the point?
Alexey

Answer 1

Sometimes I'm tempted to say that a driving design goal in SQL Server for error handling has always been maximum confusion.
The true story more likely t obe is that through the years, too little attention has been paid to this area, and once some funny behaviour has made it into the product, they are very anxious to change it, as it could break existing applications.
With SET XACT_ABORT ON, most errors abort the batch and roll back the transaction, but there is a small class of errors that do not:
* Syntax errors.
* RAISERROR.
* Error 266 (trancount mismatch).
* Dropping a non-existing table and a few more.
Once can note that in SQL 2000, binding errors (e.g. missing table) were also unaffected by XACT_ABORT, but luckily they did have the guts to change that in SQL 2005.
To muddle the waters even further, in SQL 2012 they introduced the ;THROW statement which serves the same purpose as RAISERROR, but ;THROW aborts the batch. However, if XACT_ABORT is OFF, ;THROW does not roll back the transaction, a behaviour not seen before
SQL 2012. As I said, confusion is a driving design goal for error handling in SQL Server.
Erland Sommarskog, SQL Server MVP, [email protected]