Error handling in backends.

Development matplotlib-devel
1

OK - I think I've read most of those messages and had a few

    > comments/ideas. Soapbox mode on: Please don't change the
    > system exception hook. Matplotlib (MPL) is not an
    > application, it's a library. Libraries should never change
    > global behavior - only applications. By changing global
    > behavior you severely limit how and where your library can be
    > used by others. Soapbox mode off.

Point taken. One might view the pylab interface as an application,
but I won't quibble.

    > I wonder if it helps to think about errors from a different
    > stand point. For example, I can think of two high level
    > views that might help. Users interact with MPL either
    > through the Python command line (via typing or scripts) or
    > through GUI front ends.

    > 1) A python function is called which has an error (or
    > something it calls has an error, etc, etc). In this case, if
    > the function throws an exception, python will propagate the
    > exception normally. If you're typing something on the prompt
    > or running a script, the exception get's printed with a trace
    > back. Very useful and very normal for Python.

There is a wrinkle here. On win32 (or another platform that binds
python scripts to an executable), you might double click on a script

  from pylab import *
  semilogy([0,1,2,3])
  show()

In pre 0.72 mpl, this would throw an exception. On windows, if you
double clicked this script, a stdout window would launch and die
before you could read the traceback -- very annoying. That's the
primary reason I tried to catch exceptions in the pylab interface and
forward them on to the error_msg handler function. But the current
impl. is admittedly broken. Do you have a suggestion for how to
handle this case?

We could do something like this: all GUIs define a function
show_message. This pops up a message dialog with a single OK button.
pylab dies the following

def plot(*args, **kwargs):
    # allow callers to override the hold state by passing hold=True|False
    b = ishold()
    h = popd(kwargs, 'hold', None)
    if h is not None:
        hold(h)
    try:
        ret = gca().plot(*args, **kwargs)
    except:
        msg = ...get the traceback as string ...
        show_message(msg)
        hold(b)
        ...rethrow the same exception....
    else:
        try: draw_if_interactive()
        except:
            msg = ...get the traceback as string...
            show_message(msg)
            hold(b)
            ...rethrow the same exception....
        
        hold(b)
        return ret

Someone please remind me how to rethrow the last exception --
Fernando?

Or we could just ignore it and let win32 users who are double clicking
scripts die the painful death they deserve. It would certainly make
for cleaner pylab code.

    > - Error trying to save the plot to the image file 'plot.png'.
    > - Error in the automatic plot layout algorithm. - Error in
    > setting the size of the plot region. The inputs size of
    > [-10, 200] is invalid.

This gives you more diagnostic information in that you get helpful
messages at each level, but the standard traceback gives you all the
levels, no?

JDH

2

John Hunter wrote:

Someone please remind me how to rethrow the last exception --
Fernando?

try:
   foo
except E:
   print 'I caught E, now I will raise it'
   raise

Best,

f

3

I like the idea of keeping pylab simpler. It's too bad there is no easy way to handle executable python code from Windows. Of course, windows users could write a small wrapper that traps exceptions, prints them, and then waits for a keypress - but that might be too much to ask. I think about it some more...

I would vote for not having GUI messages being popped up from a script. A quick poll of our users also indicates that they expect script errors to be like python and appear in the script.

One thing to think about is that if you dump all errors into a GUI, you limit the ability to use matplotlib in some applications. For example, we're considering writing a real-time plotting application that reads data from the network and keeps a screen updated of the current status (in this case, we want to plot real-time data read from spacecraft telemetry) for several teams to look at. This application needs to be very robust and handle errors explicitly so that it remains running at all times. It's generally going to be displayed on a monitor away from the computer for people to see.

Since this is an automated system, it could end up trying to executing some plot command that is invalid (the down link data sometimes becomes corrupted for example). In this case, we want to catch the MPL exception and discard the last data packet or do some other type of data handling. If the error pops up a dialog, then my program is basically done for because there is no user to click the OK button.

Could we set some type of option in the config file that would allow either behavior?

Ted

···

At 01:43 PM 2/14/2005, John Hunter wrote:

    > OK - I think I've read most of those messages and had a few
    > comments/ideas. Soapbox mode on: Please don't change the
    > system exception hook. Matplotlib (MPL) is not an
    > application, it's a library. Libraries should never change
    > global behavior - only applications. By changing global
    > behavior you severely limit how and where your library can be
    > used by others. Soapbox mode off.

Point taken. One might view the pylab interface as an application,
but I won't quibble.

    > I wonder if it helps to think about errors from a different
    > stand point. For example, I can think of two high level
    > views that might help. Users interact with MPL either
    > through the Python command line (via typing or scripts) or
    > through GUI front ends.

    > 1) A python function is called which has an error (or
    > something it calls has an error, etc, etc). In this case, if
    > the function throws an exception, python will propagate the
    > exception normally. If you're typing something on the prompt
    > or running a script, the exception get's printed with a trace
    > back. Very useful and very normal for Python.

There is a wrinkle here. On win32 (or another platform that binds
python scripts to an executable), you might double click on a script

  from pylab import *
  semilogy([0,1,2,3])
  show()

In pre 0.72 mpl, this would throw an exception. On windows, if you
double clicked this script, a stdout window would launch and die
before you could read the traceback -- very annoying. That's the
primary reason I tried to catch exceptions in the pylab interface and
forward them on to the error_msg handler function. But the current
impl. is admittedly broken. Do you have a suggestion for how to
handle this case?

We could do something like this: all GUIs define a function
show_message. This pops up a message dialog with a single OK button.
pylab dies the following

def plot(*args, **kwargs):
    # allow callers to override the hold state by passing hold=True|False
    b = ishold()
    h = popd(kwargs, 'hold', None)
    if h is not None:
        hold(h)
    try:
        ret = gca().plot(*args, **kwargs)
    except:
        msg = ...get the traceback as string ...
        show_message(msg)
        hold(b)
        ...rethrow the same exception....
    else:
        try: draw_if_interactive()
        except:
            msg = ...get the traceback as string...
            show_message(msg)
            hold(b)
            ...rethrow the same exception....

        hold(b)
        return ret

Someone please remind me how to rethrow the last exception --
Fernando?

Or we could just ignore it and let win32 users who are double clicking
scripts die the painful death they deserve. It would certainly make
for cleaner pylab code.

    > - Error trying to save the plot to the image file 'plot.png'.
    > - Error in the automatic plot layout algorithm. - Error in
    > setting the size of the plot region. The inputs size of
    > [-10, 200] is invalid.

This gives you more diagnostic information in that you get helpful
messages at each level, but the standard traceback gives you all the
levels, no?

JDH

Ted Drain Jet Propulsion Laboratory ted.drain@...179...