Re: Good practice for error-handling

Kim,

My error handling strategy, is much the same:

I create a public DB interface using SPs (abstracts the DB structure from
code), those SPs have a return value set with SP logic to indicate
conditions which would not cause SQLServer to raise an error condition. It's
worth noting that if you use RAISEERROR in an SP, the SP is terminated
immediately, if the SP has a return value it wouldn't be set.

If I've squirted a SELECT direct to the datasource (rather than using an SP
which is sometimes necessary), or, if x.Open(...) returns an error HRESULT,
I collect the oledb errors collection, package it up (perhaps with some
re-interpretation after examining the oledb errors) and set a COM errorinfo
for the client then return an appropriate HRESULT to the caller.

If x.Open(...) returns a success HRESULT, I examine the return value of the
SP, if it indicates an error, I set a COM errorinfo for the client and
return an appropriate HRESULT to the caller.

Reinterpretation:
Often I examine the oledb errors collection and create COM errorinfo based
on the native sql error code, and not bother with the descriptions, because
the oledb error descriptions are rather "dry".
Eg. If I encounter ref integrity errors (PK violation, FK constraint
violation etc) while trying to say add some logical entity, I'll set a COM
errorinfo and return HRESULT that is more appropriate ("CoolBean cannot be
added because another CoolBean exists with the same primary key value")
Obviously this reinterpretation only reinterprets certain sql error codes,
if an oledb error is not one of the native sql error codes that I "catch", I
just return the native oledb error description.

Regards,
Phillip Allan-Harding

Graphicboost Ltd.
Tel: +44(0) 161 980 4136
Mobile: +44(0) 7778 561119
Email: [email protected] <mailto:[email protected]>
Web: http://www.graphicboost.com <http://www.graphicboost.com>


-----Original Message-----
From: Kim Gräsman [mailto:[email protected]]
Sent: Thursday, 05 September 2002 20:15
Subject: Good practice for error-handling


Hello,

I've been a bit unhappy with our error handling for a while. We've got a
bunch of COM components using the ATL OLEDB wrappers exclusively to execute
stored procedures.

Sometimes the sp's are simple SELECT's, and sometimes they contain more
logic. For the latter category, sometimes I feel like raising specific
errors on sp-logic rather than referential integrity.

How can I manage this? Does RAISEERROR come out as an HRESULT?

Thankful for any pointers,
Kim

You can read messages from the OLEDB_DEV archive, unsubscribe from
OLEDB_DEV,
or subscribe to other DevelopMentor lists at http://discuss.develop.com.

You can read messages from the OLEDB_DEV archive, unsubscribe from OLEDB_DEV,
or subscribe to other DevelopMentor lists at http://discuss.develop.com.