Sorry, I am still not clear about this function. What is
> its purpose? When will it be called?
Good question. In simple cases the matlab interface calls this
function if illegal arguments are passed, eg if you call axis with the
wrong signature
if len(v) != 4:
error_msg('v must contain [xmin xmax ymin ymax]')
return
This just displays the error and returns, non-fatal. In other
functions, it does forwards the traceback message on to the error_msg
function and then re-raises. This is done to prevent the gui from
swallowing the traceback.
But there is no coherent policy in the matlab interface in how error
handling is done. Eg, in savefig, which calls print_figure
for key in ('dpi', 'facecolor', 'edgecolor'):
if not kwargs.has_key(key):
kwargs[key] = rcParams['savefig.%s'%key]
manager = get_current_fig_manager()
manager.canvas.print_figure(*args, **kwargs)
There is no try/except handling of print_figure.
The leads to the question: which exceptions should the matlab
interface handle when calling the backend? Do we do the extra work of
defining the exception policy of backend functions and just catch
these. Or do we catch all exceptions, forward the exception message
to error_msg, and then re-raise the identical exception. The latter
sounds reasonably coherent.
Or do we start over with a new design? Wandering into murky waters
here, is it possible for the GUIs simply to add an exception hook to
hook the tracebacks into a GUI dialog box, and simply do away with
error_msg all-together? I'm starting to like the sound of that.
JDH