exception handling architecture

Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

All Forums

SQL Server 2000 Forums

SQL Server Development (2000)

exception handling architecture

Author

Topic

shmecher
Starting Member

10 Posts

Posted - 2005-01-26 : 11:06:55

Hi. I'm trying to come up with a plan on exception handling in my stored procedures, and I have some questions.

First of all, I went through some documents explaining exception handling in SQL Server (http://www.sommarskog.se/error-handling-I.html, http://www.sommarskog.se/error-handling-II.html) and I came up with the following plan:
1. check the @@error variable after each statement (INSERT, UPDATE, DELETE, CREATE temp_table, SELECT INTO temp_table) in all my stored procedures and return the error (upon the first error)
eg UPDATE some_table...
SELECT @err = @error IF @err<>0 RETURN @err
2. check @@error after calling a stored procedure and return the error
EXEC @err = some_sp
SELECT @err = isnull(@err, @@error) IF @err<>0 RETURN @err

I've ommited transaction rollback into this check, because every time I start my procedures (whose task is to load some tables with given data) I have an unload procedure that simulates rollbacks.

I do handle dynamic SQL and function differently (like in the articles). Data errors (eg delete from a table and rowcount is 0) are also handled differently.

Am I missing something? Is there an essential validation in building an exception architecture that I'm missing? Is there anything else that I should consider?

Thanks,
TIBM

X002548
Not Just a Number

15586 Posts

Posted - 2005-01-26 : 13:15:11

Well...I would reccomend against using the Return value as a check. SQL Server could override that value, and if you could for a specific value, you could get erroneous results.

Better to use an output variable

And there are 3 types of errors (I Think).

1. User errors, like the one you mentioned...I want to do an update but @@ROWCOUNT says nothing got updated
2. System Errors that return their values to @@ERROR, and
3. Fatal errors that just raise out and you have no control over..that's where checking the return value is helpful

I use this template almost exclusively

http://weblogs.sqlteam.com/brettk/archive/2004/05/25/1378.aspx

And why would you want to mimic a rollback...just let sql server handle that for you..because you are just doubling the tlogs that way

Brett

8-)

Subscribe to SQLTeam.com

SQLTeam.com Articles via RSS

SQLTeam.com Weblog via RSS

- Advertisement -

Resources