Re: [GNUe-dev] Proposal: Handling of "uncaught exceptions" in forms

[Jason Cater]

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