propagation of error messages in matplotlib

By subclassing Verbose you group all the functions that

    > display messages to the user together into one class. I
    > may have misunderstood some of the discussion - I agree
    > with doing all error handling with exceptions, but when you
    > catch the exception in a GUI I'm assuming you still want to
    > popup a message to inform the user. Are you describing
    > using exceptions and tracebacks without any error messages
    > for GUI backends? I don't think you can assume a GUI
    > backend user will see a traceback since the terminal window
    > may be obscured, iconified or even closed.

For the GUI error handling, I was assuming we would use the
except_hook, and do away with error reporting in the verbose class.

For the regular verbose reporting, I'm not averse to plugging it into
a GUI dialog, but I'm not sure this is useful. As I wrote before,
this will mainly be used in debug situations when we can probably
assume a user has access to a shell output. They can always capture
it to a file using the regular rc mechanism of setting verbose.fileo.

If we did want to do it in a GUI, we would have to be fairly careful
about the implementation, so that the GUI cached sequential methods
and only displayed them if some time interval (eg 100ms) had lapsed
with no new messages. This would be used to prevent the curse of 20
popups. This could presumably be done in GTK with an idle handler and
a changed timestamp.

Alternatively, it could be done in the verbose base class itself,
implemented using threads, but I'm a little wary of the extra
complexity here.

That said, I think that having the figure manager define a
popup_dialog method would be generally useful.

    > It does look like they are all non-fatal. I guess the fatal
    > ones are the ones that matplotlib does not anticipate or
    > catch, thinks like faulty installations, missing libraries
    > etc. At the moment these would cause matplotlib to
    > terminate but if we add a default exception handler we will
    > start catching these also. We could have a policy for
    > matplotlib to catch all exceptions and always attempt to
    > continue, and if it becomes unusable its up to the user to
    > close the window. Also we could recognise some situations
    > (if there are any) where we need to terminate, so we raise
    > SystemExit and set the default exception handler to
    > terminate on SystemExit and continue on all other cases.

Sounds right to me.... So in summary, if all agree and we've covered
all the bases, Verbose.report_error and error_msg disappear and are
replaced by regular exceptions. matplotlib code can raise a
SystemExit for the relatively rare fatal errors. GUIs define
sys.excepthook = exception_handler following the lead of Steve's
implementation in backend_gtk (in CVS).

verbose.report is left untouched for now but may be hooked into a GUI
reporting functionality if we can resolve the issues of whether this
is desirable and how to handle caching of many independent sequential
messages.

JDH

John Hunter schrieb:

"Steve" == Steve Chaplin <stevech1097@...49...> writes:

    > By subclassing Verbose you group all the functions that
    > display messages to the user together into one class. I
    > may have misunderstood some of the discussion - I agree
    > with doing all error handling with exceptions, but when you
    > catch the exception in a GUI I'm assuming you still want to
    > popup a message to inform the user. Are you describing
    > using exceptions and tracebacks without any error messages
    > for GUI backends? I don't think you can assume a GUI
    > backend user will see a traceback since the terminal window
    > may be obscured, iconified or even closed.

For the GUI error handling, I was assuming we would use the
except_hook, and do away with error reporting in the verbose class.

I'd like to strongly plead that you stay away from sys.excepthook.

That is the 'last resort' tool to manipulate exceptions, and it's typically used by frameworks which need to completely control the python process. For example, ipython puts its internal crash handler in sys.excepthook, so that if all else fails, the crash handler generates a very detailed crash report. But all 'normal' exception handling is done by the internal user loop, with manual control.

I haven't had time to look in detail, but I even think that ipython pretty aggressively reclaims sys.excepthook if user code messes with it. I wouldn't be surprised if other frameworks (like envisage) also used sys.excepthook themselves. Matplotlib is 'only' a plotting library :), and it should IMHO play nicely with other code running along with it. If it gets into a foodfight over who owns sys.excepthook, or if it crashes because sys.excepthook is not what it thinks it is, I expect serious interoperability problems to pop up down the road.

I realize that excepthook is a tempting tool to use, but I hope you guys reconsider this. I really think it would cause many more headaches down the road than those it initially appears to solve.

Regards,

f