May 11, 2004 at 3:59 am
A friend of mine recently said that he remembered reading an article where it was suggested that a single stored procedure should be in place to handle errors from all other stored procedures. Thus centralising the code for easier maintenance.
I personally code error handling into each of my stored procedures.
I am interested to know if anyone out there adopts the policy of one sibgle SP to catch all, or even if it is possible to do.
May 12, 2004 at 8:34 am
To be honest, I'm not sure how a single stored proc could technically trap all errors, as the call to the stored proc would mask some errors.
I generally implement a variation on the concept in each of my systems.
I trap for errors within each stored proc after each call that I care about. I think this is ho most of us do this. However, once trapped, I send the errors to a single stored proc for logging and triggering appropriate alerts back to the user. I implement a "@ResultCode OUTPUT" from every stored proc that the error management proc uses to pass information back up the call stack. In some sense, this is an "error management subsystem".
Maybe I'll do an article on the subsystem, as it has evolved over 20 years and is fairly robust .
May 12, 2004 at 8:48 am
Thanks wlawton. I think you're right about one sp logging and alerting and maybe that was where my friend saw it.
However, I was thinking that one sp could conceivably be passed a parameter from another sp so that it could take some action of some kind.
Anyhows, I am interested in the "@ResultCode OUTPUT" option. I will have take a real good look....
And yes, by all means do an article on it. I will keep a lookout for it.
Viewing 3 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply