From: John H. <jdh...@ac...> - 2004-11-18 17:00:16
|
>>>>> "Jochen" == Jochen Voss <vo...@se...> writes: Jochen> Sorry, I am still not clear about this function. What is Jochen> 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 |