[DB-SIG] what's wrong an exception-catching class?

Jim Hefferon jim@joshua.smcvt.edu
Tue, 26 Nov 2002 14:11:31 -0500


Hi.  

I am new to db programming in Python, so forgive me if this is an
easy one; I've looked for the answer in groups.google.com, on
a few months of this list, and at google in general, but I've not 
found it.

The 2.0 specification doesn't delimit which exceptions
each operation may raise.  I'm doing a web interface thing and I'd
like to be very careful, and in addtion provide as much information
about any error as possible.  

So I thought to make a class dbOp with a method
  
  def submit(self):
    try:
      self.operation()       
    except PgSQL.DataError, err:
      raise dbError, self.handleDataError(err)
    except PgSQL.OperationalError, err:
      raise dbError, self.handleOperationalError(err)
    ... etc: every legal exception is handled ...

where the handle* routines do things like print a sensible error
message, produce the traceback, etc.  This way, I can subclass to
dbConnect where the operation method makes a connection and creates a
cursor.  I can also subclass to dbQuery where the operation runs
self.cursor.execute(...)  (for this one __init__ gets the cursor
and the statement when the instantation is made).  I can share 
working code if I've not explained myself enough.

Now, the question.  This seems to me to be the natural thing to
do.  But I've not found versions of this code anywhere, nor have
I seen this approach mentioned; this includes books on the subject.  
Is there some tremendous drawback?

That is, my try is obvious enough that the fact that I can't find it used 
makes me think that it must be obvious but wrong-headed.  Is it?

Thanks,
Jim