propagation of error messages in matplotlib

Actually, it would be fine if matplotlib overrode

    >> sys.except_hook and ipython later came along and overrode that.
    >> Basically, ipython would be saying, "I know I've got a shell to
    >> display errors in, so we don't need to GUI method". I don't
    >> think matplotlib would have a problem with that. Ditto for
    >> envisage. Basically, we would be providing a default method to
    >> get the message to the GUI which could be overriden by other
    >> applications that want to (ipython, envisage, what-have-you).

    > I guess this is a good heads-up for me. I know ipython
    > does some of this, I'll just add a bit more such
    > control. That way, if during the running of user code
    > they need sys.ehook for something, they'll get it. But
    > ipython will keep it for when it needs it. I'm pretty
    > sure the embeddable ipython has such control in it, I
    > may just need to put it in the general case as well.

    > Ultimately I'm not 100% sure what a good solution for
    > matplotlib is, I just wanted to make you aware of these
    > issues, so that at least they are on your radar.

We do have some more options. For one, we could use the excepthook
only in the matlab interface -- in this case matlab is being used more
as an application rather than a library. Folks using matplotlib as a
library, eg embedding in a GUI, would be advised to do their own
trapping.

The only exceptional case I see is basically the ipython (and friends)
case. Ie, someone wants to write a shell or otherwise that embeds
matplotlib.matlab. In this case it would be fine to override
matplotlib.matlab's excepthook, as discussed.

To play really nicely, matplotlib.matlab would like to be able to
override excepthook only if it hadn't been otherwise overridden. I
don't see any elegant way to do this. Any ideas?

JDH

John Hunter schrieb:

"Fernando" == Fernando Perez <Fernando.Perez@...76...> writes:

    >> Actually, it would be fine if matplotlib overrode
    >> sys.except_hook and ipython later came along and overrode that.
    >> Basically, ipython would be saying, "I know I've got a shell to
    >> display errors in, so we don't need to GUI method". I don't
    >> think matplotlib would have a problem with that. Ditto for
    >> envisage. Basically, we would be providing a default method to
    >> get the message to the GUI which could be overriden by other
    >> applications that want to (ipython, envisage, what-have-you).

    > I guess this is a good heads-up for me. I know ipython
    > does some of this, I'll just add a bit more such
    > control. That way, if during the running of user code
    > they need sys.ehook for something, they'll get it. But
    > ipython will keep it for when it needs it. I'm pretty
    > sure the embeddable ipython has such control in it, I
    > may just need to put it in the general case as well.

    > Ultimately I'm not 100% sure what a good solution for
    > matplotlib is, I just wanted to make you aware of these
    > issues, so that at least they are on your radar.

We do have some more options. For one, we could use the excepthook
only in the matlab interface -- in this case matlab is being used more
as an application rather than a library. Folks using matplotlib as a
library, eg embedding in a GUI, would be advised to do their own
trapping.

The only exceptional case I see is basically the ipython (and friends)
case. Ie, someone wants to write a shell or otherwise that embeds
matplotlib.matlab. In this case it would be fine to override
matplotlib.matlab's excepthook, as discussed.

To play really nicely, matplotlib.matlab would like to be able to
override excepthook only if it hadn't been otherwise overridden. I
don't see any elegant way to do this. Any ideas?

Yup:

planck[mayavi]> ip
In [1]: import sys

In [2]: sys.__excepthook__ is sys.excepthook
Out[2]: False

planck[mayavi]> python
>>> import sys
>>> sys.__excepthook__ is sys.excepthook
True

Cheers,

f

I've updated backend_gtk.py in cvs to use a default exception handler,
and noticed a few things in the process:
- sys.excepthook does not catch SystemExit, which is what we wanted
anyway.

- for some errors I needed to display a matplotlib message rather than
the default exception message, or to raise an exception where error_msg
() was used with no exception. I added an 'MPLError' exception, its
probably best to move it into a central file if other people need to use
it also.

- changing from error_msg() to raise exception means the rest of the
method will not execute, which I hadn't thought about. This is no good
for 'get_filename_from_user()' where I want to loop until a file (or
Cancel) is selected. So I think GTK still has a need to use of a popup
message dialog occasionally.
And for print_figure() it means the section of code to restore figure
settings will not get executed after an error.

Steve