[DB-SIG] Remaining issues with DB API 2.0
Sun, 28 Mar 1999 14:45:48 -0800
M.-A. Lemburg wrote:
> > > * 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 ?
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.
Greg Stein, http://www.lyra.org/