Re: [Gnumed-devel] catching errors in an app

[J Busser]

Some interlacing of the most recent thread. Karsten has updated the wiki a bit on DevelopmentGuidelines, I could link up the following, too.

On Wed, Jan 25, 2006 at 08:41:19AM +1100, Richard wrote:

> I guess this is well implemented in gnumed.
Unfortunately not. There was talk about how to improve it
fairly recently on the list.

> Karsten I wonder if you could point me in a direction.
We got a "top level" exception handler in client/gnumed.py
which wraps the entire client.

However, wxPython catches exceptions inside it's event

handler AFAIK and they never propagate beyond that.

This was partly known among the GNUmed group but

confirmed by Robin Dunn from http://wxpython.org:

> > Currently exceptions are not passed through
> > the C++ layers so if you want to catch them
> > you
> > need to do it in each event handler or
> > callback.

OTOH we also have a bit of somewhat generic error handling
in pycommon/gmBusinessDBObject.py but this only applies to

its subclasses.

We also have gmGuiHelpers.gm_show_error() and friends to
ease notification about errors.

> Do we have a global error catching module, or specific error

> routines for each subroutine.

Well, each error that can be usefully handled needs to be
handled where it occurs. Other errors should throw
exceptions as we agreed. However, it is at times a very hard
decision which errors can be handled and which cannot be
handled. It is also sometimes not in the power of the called

subroutine to even theoretically *have* that knowledge.

At 10:55 AM +0800 1/27/06, address@hidden wrote:

> The problem is in Python, everything is
> an exception, even syntax errors,
> which are silently gobbled by the wxPython core, unless you
> provide
> an exception handler.
>
> Personally want I'd like to see is a single generic handler at the
> top
> of the stack (so called from the GUI event handler) which writes to
> the log
> and presents a sensible dialog box to the user. 99.99% of the time
> this is the
> only sensible thing to do anyway, this simplifies the rest of the
> code
> massively.