[DB-SIG] Remaining issues with DB API 2.0

[M.-A. Lemburg]

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 ?

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 ?!

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