since the various DBAPI error classes are implemented within each DBAPI module (i.e. psycopg2.IntegrityError, pysqlite2.dbapi2.IntegrityError, etc), it makes it impossible to write DBAPI-neutral code if you want to catch those errors directly.
also things like the error code and such we'd eventually like to have available off of SQLError but most DBAPIs dont seem to implement these (and i see below youve located some more of those endlessly- undocumented PG datamembers....) On Jan 30, 2007, at 6:15 PM, Thomas Hunger wrote: > > Hello, > > I was wondering if there is a special reason to wrap the db api > exceptions like e.g. "IntegrityError" into an SQLError. > > The code could execute self._autorollback() and just rise the > exception again. > > This would make much nicer exception handling (at least for me) in > situations like > > ... > session.flush() > except IntegrityError, integrity_error: > # handle error > > instread of > > session.flush() > except SQLError, e: > if (e.orig.pgcode == 23505): # handle 1 > if (e.orig.pgcode == xxxxx): # etc > > > Tom > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
