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.
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.
2) A GUI widget calls a function which has an error. If the function throws an exception, the GUI should trap that exception and show a dialog or whatever is appropriate for that GUI.
So I guess I'm wondering what happens if we just throw standard Python exceptions for all errors? From the Python interface you get normal Python behavior regardless of the front end (Tk,Qt,Gtk,Agg,etc). If you executed some operation from the front end (like clicking the save file dialog in the toolbar), you get a GUI error message like any normal GUI. Is this too simple of a view?
As an aside, we've found that using error stack classes work very well in exception error handling. Most of our code throws an error stack class which holds an array of error messages. This way you can trap errors and add an error message with context information at various levels. Many times errors happen at the lowest levels and you don't really know why that function was called.
As a completely contrived example (and probably stupid), let's say you were saving a plot to an image and the plot had to resize/re-render to get to the right image format. You might get an error back that looks like this:
- 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.
I realize this example doesn't make a lot of sense but hopefully it gives you some idea what you can do. In this case the lowest level function which sets the size of the region decided that the inputs were invalid. If you just propagate that error to the user, they may not have any idea why that function was called in the first place. So the higher level functions do a try...except loop where they add context messages to the error and then re-throw it. This has really helped our users get useful error messages when something goes wrong at the lowest level.
I don't know if that makes any sense or would help with error reporting in MPL so feel free to ignore it completely. It was just something that has helped us a lot in using exceptions to provide useful messages to people.
Ted
···
At 11:16 AM 2/14/2005, John Hunter wrote:
> Also, I'm a little confused about the backends use of the
> 'error_msg' function. Many of the backends import this
> function from backend_bases but then change that names
> definition to a local copy (see backend_gtk,
> backend_template, backend_wx). This seems wrong or at least
> more confusing that it needs to be. I don't think a script
> should explicitly import something with one name and then
> change the name to point to a local variable.
We're a little confused too 
The error_msg function was initially designed to provide a way to get
error messages up to the GUI, otherwise they might disappear into
stderr, stdout. However, the framework has caused nothing but grief
and confusion and needs to die. It has lived this long simply because
noone has found the time to kill it. The system exit in the default
error message function was meant to be used by image backends with the
reasoning that if you get an error on an image backend, there is no
point in trying to continue. But now I see the unintended
consequences of this decision when we mix image and gui backends, as
in qt agg.
There have been prolonged discussions on the topic before. See for
example the "propagation of errors thread at CVS
http://sourceforge.net/mailarchive/forum.php?forum_id=36187&max_rows=100&style=threaded&viewmonth=200411
where we almost reach a consensus and then promptly repress the
subject for a few more months. Last time we left off, I think I
suggested that we should kill error message and use exception hooks to
get the exceptions into the GUI. Steve tried to implement something
like this for GTK -- I can't remember what the final result was.
I think a good place to start would be to remove all instances of
error_msg* from the mpl front end and backend code, and then see where
we are. Any major problems with that?
JDH
Ted Drain Jet Propulsion Laboratory ted.drain@...179...