[DB-SIG] Remaining issues with DB API 2.0

[Greg Stein]

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.

> 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.

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

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

Cheers,
-g

--
Greg Stein, http://www.lyra.org/