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?
I think in the backend and other matplotlib code where we know how to
handle the exception, this makes sense. Eg, if backend_gtk gets a
IOError on some file, it can catch it and request a new filename. We
should catch and handle exceptions where we can.
Buy I'm thinking about the matlab interface. There are two problems
in matlab.py: 1) There are practically no exceptions that we can
handle at that level so the best we can do it forward it on the user
and 2) there is no single point to plug in a master exception handler.
Consider the canonical matlab interface function
def plot(*args, **kwargs):
ret = gca().plot(*args, **kwargs)
draw_if_interactive()
gca().plot makes a series of deeply nested calls, as does
draw_if_interactive. With these two calls, a substantial number of
the total methods defined in matplotlib are actually called (format
string parsers, line instantiation, transformations, clipping, gcs,
renderers, font finding, etc, etc....) There are a lot of potential
exceptions to be thrown, and tracking down all of them would be a big
task. And then once we catch them what could we do with them?
The problem is compounded by the fact that the solution would have to
repeated for *every* matlab interface function separately, which looks
like it would lead to a big tangle of unmanageable code across the
whole module.
Perhaps I'm missing the obvious thing and not understanding your
suggestion. But form my end at the level of the matlab interface, the
best we can do is get a helpful, descriptive error message to the
user. Did you have another approach in mind?
JDH