From: John H. <jdh...@ac...> - 2004-11-19 15:23:57
|
>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes: Steve> At the moment we have error_msg(), the Verbose class and Steve> exceptions all working in the same area and a bit of Steve> confusion as to which one does what. I don't think we need Steve> all three. Steve> I suggest - using exceptions to handle errors that may Steve> terminate the program, and allowing the matlab interface, Steve> GUI backends and user scripts to catch these exceptions. - Steve> using verbose for all reporting - merging error_msg() into Steve> the Verbose class (with the GUI backends possibly Steve> subclassing Verbose to provide a popup error dialog) I think you are right that the plethora of error reporting strategies is causing confusion, especially for me! I like the idea of the GUI backends overriding placing a hook into the python exception handling process. One possibility would be to do away with verbose.report_error and error_msg. The GUIs hook into the exception message, and anywhere we want to report an error we raise a python exception. And we continue to use verbose.report as before. I just checked backend_ps and the only place is uses error_msg is error_msg_ps('Could not open %s for writing' % outfile) which would be more naturally handled as an exception anyway. Steve, could you look into hooking a GTK dialog into the python exception reporting mechanism to see if this is viable? In summary, the thought is * use verbose only for non-error reporting * use exceptions for all error reporting * work some GUI magic to transparently get the errors forwarded to a dialog box w/o using special functions As for verbose.report, I'm not convinced it is a good idea to hook this into the GUI. For one thing, some reporting occurs before the backend is determined. For another, it would also require some caching of messages because if 30 messages generate 30 popups it will get annoying quick. These things are manageable, but I think the main use for verbose.report is debugging a problem, in which case simply having the messages go to a stdout or a file may be the best place for them. JDH |