Re: [matplotlib-devel] propagation of error messages in matplotlib

[John H. <jdh...@ac...>]

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:

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

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