[DB-SIG] db module wrapper

Clark, Chris M Chris.Clark at ca.com
Sat Aug 21 01:06:29 CEST 2004


> -----Original Message-----
> From: db-sig-bounces+clach04=ca.com at python.org
> [mailto:db-sig-bounces+clach04=ca.com at python.org]On Behalf Of Randall
> Smith
> Sent: Friday, August 20, 2004 2:53 PM
> To: Python DB-SIG Mailing List
> Subject: Re: [DB-SIG] db module wrapper
> 
> 
> About exceptions.
> 
> I'm just throwing this out.  Tell me what you think.
> 

.... Cut
 
> {'pyscopg_1.1.15': 'exc_trans execute DatebaseError ProgrammingError'}
> Which means:  When the execute method raises a Database 
> error, transform 
> it to a Programming error.
> 

(Possibly naive) Question: what problem would be solved by translating/renaming exceptions? I've had a look at Kevin Jacobs exception virtualization code and it hides (very well) WHICH driver raised the exception which seems to be the bug problem for portable applications. I'm trying to figure out why one would want to rename the exception type.

If the issue is that a driver isn't returning a sensible (or consistent with other drivers) exception this sounds like a weakness in the driver ( or possibly the 2.0 DBI spec. it depends on the circumstances). Do you have an example of a specific scenario when the Database error occurs for PostgreSQL when it makes more sense to raise a ProgrammingError? It may make more sense for the Postgres DBI driver to be updated rather than introducing another layer (I'm conveniently ignoring backwards compatibility for now :-p).

On the subject of the 2.0 spec and exceptions; I've been working with a colleague to create a (replacement) driver to Ingres <pimp database> http://opensource.ca.com/projects/ingres/ </pimp database> and one of the gotchas I had (I'm willing to accept I don't full comprehend 2.0 spec :-p) was that I wasn't clear under exactly what circumstances various exceptions I should be raised. http://www.python.org/peps/pep-0249.html lists the exceptions and some guides of when but it wasn't fully specified.

E.g. instead of generating a Database exception whenever the DBMS sends an error back I check for various errors (duplicate key on insert, foreign key failures, etc) so that an IntegrityError is raised instead. I think it would be useful if a more explicit list of examples where available in the spec (such as "duplicate key on insert"). I'm still working out what exceptions we are going to raise and when so I don't have such a definitive list myself but we are working on something like that.

Any comments? Have I misunderstood the problem? Is this something that would be a candidate for say a 2.1 DBI spec (or 3.0, etc.).

> Anything not specified in the config would simply transform from 
> psycopg.Error to wrapper.Error

As per above, I'd rather the DBI drivers return consistent exceptions.

Chris



More information about the DB-SIG mailing list