Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

Our insert happens correctly, so no error condition is detected (because there isn’t one).
(1 row(s) affected)
New Record Inserted
Now, try something that should blow up:
EXEC spInsertValidatedBusinessEntityContact 0, 1, 11;
And you see not only the actual SQL Server message, but the message from our error trap (note that
there is no way of squelching the SQL Server message).
Msg 547, Level 16, State 0, Procedure spInsertValidatedBusinessEntityContact, Line
11
The INSERT statement conflicted with the FOREIGN KEY constraint
“FK_BusinessEntityContact_Person_PersonID”. The conflict occurred in database
“AdventureWorks2008”, table “Person.Person”, column ‘BusinessEntityID’.
The statement has been terminated.
At least one provided parameter was not found. Correct and retry
As you can see, we were able to detect our error without a TRY/CATCH block.
Now, let’s move on to an example of why TRY/CATCH is better — a situation where a TRY/CATCH works
fine, but where inline error checking fails. To show this one off, all we need to do is use our example for
TRY/CATCH that we used in the scripting chapter. It looked like this:
BEGIN TRY
-- Try and create our table
CREATE TABLE OurIFTest(
Col1 int PRIMARY KEY
)
END TRY
BEGIN CATCH
-- Uh oh, something went wrong, see if it’s something
-- we know what to do with
DECLARE @ErrorNo int,
@Severity tinyint,
@State smallint,
@LineNo int,
@Message nvarchar(4000);
SELECT
@ErrorNo = ERROR_NUMBER(),
@Severity = ERROR_SEVERITY(),
@State = ERROR_STATE(),
@LineNo = ERROR_LINE (),
@Message = ERROR_MESSAGE();
Chapter 12: Stored Procedures
IF @ErrorNo = 2714 -- Object exists error, we knew this might happen
PRINT ‘WARNING: Skipping CREATE as table already exists’;
ELSE -- hmm, we don’t recognize it, so report it and bail
RAISERROR(@Message, 16, 1 );
END CATCH
383