[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: J Busser
Subject: Re: [Gnumed-devel] catching errors in an app
Date: Sat, 28 Jan 2006 09:39:39 -0800

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]