[DB-SIG] Remaining issues with DB API 2.0

M.-A. Lemburg mal@lemburg.com
Mon, 29 Mar 1999 10:46:47 +0200

Greg Stein wrote:
> M.-A. Lemburg wrote:
> >
> > Greg:
> > > > * in all methods that state "an exception is raised..." we should state
> > > > *which* exception. We have a complete set defined at the beginning, so
> > > > this makes sense to do. I would recommend InterfaceError (it is based on
> > > > the interface we provide, rather than the underlying database). Hrm.
> > > > Maybe not. I can see a case where the DB module will simply attempt to
> > > > call the underlying DB function and generate a DB-related exception.
> > > > Thoughts anyone?
> > >
> > > This is hard to do, since the types of errors may very well be
> > > the whole range of possible Python exceptions + the ones defined
> > > in the DB API, e.g. a conversion routine might raise an OverflowError
> > > in case of numeric overflow while raising an InterfaceError in
> > > case a certain internal assertion failed.
> >
> > Looking at the places you probably meant, the overall generality
> > is probably not needed. We could probably restrict the exception
> > range to subclasses of Error. Would that be ok ?
> Yes.
> It would be nice to be more specific, but truthfully... I just realized
> "who cares?" The theory is that it simply doesn't happen in a correct
> program, so we don't need to load the spec up with information on how to
> tell somebody they wrote their program incorrectly.

You've got a point there. I've added the above restriction to
Error subclasses anyway; doesn't hurt, I think, and gives the
module implementor a warm fuzzy feeling that he chose the
right exception.

> > Another quirk I noticed: right now, the .nextset() method only
> > has optional functionality, always returning None in case the
> > database does not support multiple result sets. Maybe we should
> > make the method optional altogether, so that a script writer
> > can test whether multiple sets are supported or not ?!
> Well, this is a bit different from, say, rollback(). If somebody tries
> to call rollback(), then they better get a bad error because they're
> screwed if it doesn't really exist.

I thought of .callproc() as comparison. The two probably come in
pairs anyway since result sets are usually produced by stored
procedures and sometimes also by array based SELECTs (if the database
supports these).

> Calling nextset(), setinputsizes(), or setoutputsizes() doesn't really
> hurt anything. Much like commit() for transaction-less databases.

That's true, but it would be a nice way to tell wether the database
supports these beasts (which seems impossible otherwise).

Otherwise we would have to nuke the comment about the exception
raising, BTW.

> Therefore, I'd say there is much of a need for us to create additional
> exceptions or feature test requirements for users.

Feature testing can be done with hasattr() as you proposed. More
elaborate schemes will most likely turn out to be database
dependent or would result in long lists of constants in the spec.

As for additional exceptions: it might be a good idea to add
a NotSupportedError exception. This could then be used for things
like the dynamic .rollback() capability test (which would then
raise a NotSupportedError instead of an OperationalError).
It should be a subclass of OperationalError.

Maybe we should also add a note that module implementors are
free to build upon the given exception classes. Since portable
scripts would catch the exceptions using the base classes this
wouldn't hurt and give the implementors a lot more freedom.

Marc-Andre Lemburg                               Y2000: 277 days left
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :