Neil Hodgson wrote:
> Its precisely because of the engineering in OLE DB that ADO can provide
> an easy to use yet efficient facade over it. ADO Error objects are an almost
> exact translation of IErrorLookup with VB/Automation friendly types. The ADO
> Errors collection is a simple view over IErrorRecords. The basic model of an
> error stack is maintained by ADO because it is useful.
That's my point, people are using the ADO interface model, not the
OLE DB one. The ADO interface model has become the universal
currency in that environment - it covers up the OLE DB mess (I'm
speaking of OLE DB in general, not the Error stuff - 'course MY
code never has any errors ;^P *yeah, right*). I've done straight
OLE DB and it is messy. I think there is a lesson here that the
XPCOM crowd can benefit from to come up with something that
is easy to use AND to implement.
> > level." If you can't contribute something meaningful to the
> > error stack - leave it alone!
>
> And if you can contribute something meaningful, then you should. It is
> better to also maintain the lower level error as sometimes both the context
> and the specific failure are needed to analyse the problem.
>
> Neil
I have seen nested error reporting mechanisms (mostly ODBC) where
I had to dig through successive layers of "An error occurred" before
finally getting some meaningful feedback. I hate that!
Another thing: whatever the proposed scheme turns out to be - it is
going to need some sort of reference implementation to show everyone
out there how to incorporate this extra functionality into new and existing
components. Thinking out loud now, I'm wondering to what extent this
common code can be shared across multiple modules without too much
overall bloat.
-rick
