[Zope3-dev] zope.rdb error and zope.publisher error

[Brian Sutherland]

On Thu, Apr 26, 2007 at 11:09:17PM +0200, Maciej Wisniowski wrote:
> > I would personally be in favour of just ripping out DatabaseException
> > entirely and letting the original errors propagate. It's caused me a lot
> > of pain in the past by hiding real problems.
> > 
> > I have never seen any use for it.
> I think zope/rdb tries to be as general as possible, so using
> DatabaseException for all RDBMS errors may be sometimes desirable
> especially if someone builds application that
> shouldn't be bound to one, specific database adapter. But I think it
> is rather rare(?) situation,
> and there are still generic errors
> like cx_oracle.Error or psycopg.Error. They're DBMS aware but
> it shouldnt be hard to write a common handler or something like
> that if someone has to just handle all DBMS errors at once.

There are the ORM mappers SQLObject and SQLAlchemy which try to work
across different databases. But both of these seem to have specific
backends for each database they support, in which case a generic
exception like zope.rdb.interfaces.DatabaseException is not useful at
all.

In fact, it was when I was trying to integrate SQLObject and zope3 that
I developed my hatred for zope.rdb.interfaces.DatabaseException.

An interesting way that SQLObject tries to get around this issue is to
have a module attribute on the database connection. So then the
original DatabaseException from the dbapi module is always at
conn.module.DatabaseException. But I'm not sure zope.rdb should try
that. 

> Current implementation may cause some problems if someone needs real
> errors standarized by python dbapi.
> For me it would be cleaner to just have standard dbapi errors in Zope.

What does this mean? Are you suggesting implementing the full range of
dbapi errors in zope.rdb? Or letting the real errors propagate? 

One problem with ripping out zope.rdb.interfaces.DatabaseException is
backwards compatibility and deprecation. I can't think of any sane way
to do that.

-- 
Brian Sutherland