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

Chris Cogdon chris@cogdon.org
Tue, 26 Nov 2002 11:32:19 -0800


On Tuesday, Nov 26, 2002, at 11:11 US/Pacific, Jim Hefferon wrote:

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

Generally, it's not 'good form' for a library to catch exceptions. The 
whole idea of exceptions is for the 'application' to handle exceptions 
in a way that is appropriate for the application.

For example, in an interactive application, it makes sense for DB 
errors to be printed out in a descriptive way. For another application, 
say an embedded, headless, remote data-collecting facility, printing 
out exceptions is absolutely the wrong thing to do.

This is why I feel that there is no 'standard library' for catching 
exceptions, because the 'correct' thing for any particular application 
varies widely and wildly between applications.

-- 
    ("`-/")_.-'"``-._        Chris Cogdon <chris@cogdon.org>
     . . `; -._    )-;-,_`)
    (v_,)'  _  )`-.\  ``-'
   _.- _..-_/ / ((.'
((,.-'   ((,/   fL