[DB-SIG] what's wrong an exception-catching class?

[M.-A. Lemburg]

Chris Cogdon wrote:
> 
> On Tuesday, Nov 26, 2002, at 14:17 US/Pacific, Magnus Lycka wrote:
> 
>> At 11:32 2002-11-26 -0800, Chris Cogdon wrote:
>>
>>> This is why I feel that there is no 'standard library' for catching 
>>> exceptions, because the 'correct' thing for any particular 
>>> application varies widely and wildly between applications.
>>
>>
>> On the other hand, it could be useful if the raised exceptions
>> followed some kind of standard. After all, it's not the vendor
>> specific code that throws Python exceptions, it's the Python
>> database drivers. If there was a standard for these exceptions,
>> it would be easier to write generic DB-API programs. IIRC, this
>> has been discussed on this list...
> 
> 
> Oh... absolutely agree. And if the database writer needs to add in 
> special information to the exceptions, then she can subclass the 
> standard exceptions.

I don't understand... we *do* have a standard exception hierarchy
for DB-API related errors:

     This is the exception inheritance layout:

         StandardError
         |__Warning
         |__Error
            |__InterfaceError
               |__DatabaseError
                  |__DataError
                  |__OperationalError
                  |__IntegrityError
                  |__InternalError
                  |__ProgrammingError
                  |__NotSupportedError


If you write programs like so:

# Change this line if you port to another DB-API wrapper:
import myDBwrapper as dbapi

...
try:
    cursor.execute(...)
except dbapi.Error, why:
    print 'Ooops: %s' % why

you pretty much get what you want.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
_______________________________________________________________________
eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,...
Python Consulting:                               http://www.egenix.com/
Python Software:                    http://www.egenix.com/files/python/