[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNUe-dev] Proposal: Handling of "uncaught exceptions" in forms
From: |
Jason Cater |
Subject: |
Re: [GNUe-dev] Proposal: Handling of "uncaught exceptions" in forms |
Date: |
Tue, 10 Aug 2004 10:00:58 -0500 |
User-agent: |
KMail/1.6.2 |
Johannes,
I think this should be based out of GBaseApp and should work just like
handleStartupError(). Perhaps handleStartupError could be renamed to
handleError() and be made more generic.
There needs to be some mechanism for us to easily disable this catching of
exceptions when trying to code on forms, otherwise it's a real pain to debug.
Perhaps if debug-level is specified, as you mention, then exceptions are
printed. Or perhaps we should still have exceptions printed to the stdout
even if a dialog box appears. As long as a dialog appears, I don't imagine
the end user would mind output also going to stdout.
-- Jason
On Tuesday 10 August 2004 07:05 am, Johannes Vetter wrote:
> Hi,
>
> At the moment uncaught exceptions are not handled by the forms-client,
> meaning they're passed through and displayed on the starting shell. As
> we can see in the forms/uidrivers/<driver>/ErrorHandler.py
> implementations there was something like 'handleUncaughtException ()'.
> But this function doesn't work for all drivers, i.e. wx
>
> So what about the following solution:
>
> a ui-driver can implement the function "handleUncaughtException (exType,
> exValue, traceback)". If there's such a function it will be used as
> exception-hook for the sys-module (sys.excepthook). The parameters of
> this function are the same as returned by sys.exc_info () function.
>
> if a ui-driver has no such support, it should *NOT* have a
> 'handleUncaughtException'. (like wx does by now)
>
> Another idea would be if debug-level is greater than 0, the
> handleUncaughtException could include a traceback, or otherwise just
> display exception-type and message.
>
>
> Suggestions and input are welcome,
>
> Thanks,
> Johannes