On Wed, May 31, 2006 at 10:38:13PM +0300, Dan Pascu wrote:
> On Wednesday 31 May 2006 21:28, Oleg Broytmann wrote:
> to raise a single generic exception (say DatabaseError) with
> specific details about the error, or the desire is to have a hierarchy of
> exceptions like the backends have (DatabaseError, IntegrityError,
> OperationalError, ...)?
I have been thinking about the second option. Catch DB API driver's
exceptions and translate them to SQLObject's exceptions.
I believe this is what should be done, but isn't all this in pep248/249?
All exceptions and when they should be raise are there, also every exception is a subclass of those.
> Because a single generic exception will be pretty easy to add (just a
> guess without looking at the code), while having a hierarchy will be more
> complex as mappings between backend errors and sqlobject errors need to
> be made and a common denominator needs to be found between backend
> exceptions.
The biggest problem is to translate exceptions. One DB API driver raises
OperationError when another raises IntegrityError. We need to collect
information about what exceptions every driver raise in what situations.
I don't like that even if all the trace info is preserved the exception name (which something is all you need to figure out the error) is lost.
