propagation of error messages in matplotlib

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.

OK, good to know. That was news to me. Now why is it that ipython
and envisage get to mess around with it and we don't :slight_smile: ?

So what is the canonical way to funnel exceptions into GUI dialog
boxes? Isn't this what sys.except_hook is for?

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

So I don't really see a danger here, but please educate me!

JDH

John Hunter schrieb:

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

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

OK, good to know. That was news to me. Now why is it that ipython
and envisage get to mess around with it and we don't :slight_smile: ?

So what is the canonical way to funnel exceptions into GUI dialog
boxes? Isn't this what sys.except_hook is for?

Mmh, I don't really know for sure. But here's a quick test:

planck[mayavi]> egrep -r sys.except *
planck[mayavi]>

This is on the mayavi sources. Mayavi DOES show all VTK exceptions into a GUI (such as you get when you try to open the volume rendering module with floating point data, for example). I imagine it just traps them locally, but I'm not sure. It is possible that mayavi has an easier job because it's done in Tk, with no threading issues to worry about. Threads make this problem MUCH worse, since python has no sensible way for an exception raised in one thread to be handled by another: all go to the sys.excepthook bucket. There have been long, complicated threads recently on c.l.py on the cousin topics of signals and exceptions in threads, and it doesn't look pretty.

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.

Best,

f

Hello John,

So what is the canonical way to funnel exceptions into GUI dialog
boxes? Isn't this what sys.except_hook is for?

I think we should somehow explicitely catch all exceptions
we are expecting (maybe near the main loop) and the exception handler
could feed them to the backend.

Reasons:

1) This looks like the most Pythonic solution to me: exceptions
  are ment to by caught by "try: ... except: ..." statements

2) This might open a way to differentiate between expected exections
  (opening a file with a user-supplied file name might fail, if the
  user mistyped the name -> User should be told and asked for another
  file name) and unexpected ones which indicate programming errors.

3) Easier to understand flow of control. If you follow a chain of callers
  through the source code you can see which exections are caught at which
  place, whereas the except_hook mechanism is more "magical".

What do you think?

Jochen

···

On Mon, Nov 22, 2004 at 04:50:10PM -0600, John Hunter wrote:
--
http://seehuhn.de/