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