matplotlib-devel Mailing List for matplotlib

>>>>> "Jochen" == Jochen Voss <vo...@se...> writes:
 Jochen> Slight problem: it might now be a little bit more
 Jochen> difficult to include the name of the file which could not
 Jochen> be opened in the error message. The IOError exception
 Jochen> will probably only have "permission denied" associated
 Jochen> with it.
Looks OK, at least on linux
>>> file('/sbin/ldconfig', 'w')
Traceback (most recent call last):
 File "<stdin>", line 1, in ?
IOError: [Errno 13] Permission denied: '/sbin/ldconfig'

Hello,
On Fri, Nov 19, 2004 at 09:23:36AM -0600, John Hunter wrote:
> In summary, the thought is
>=20
> * use verbose only for non-error reporting
>=20
> * use exceptions for all error reporting
I agree with this.
> * work some GUI magic to transparently get the errors forwarded to a
> dialog box w/o using special functions
Here I have no opinion until I understand the special kind
of magic which is going to be used here.
> For another, it would also require some
> caching of messages because if 30 messages generate 30 popups it will
> get annoying quick.
Yes, we have to be careful here.
As nobody objected to this part of the plan, I changed the PostScript
backend in CVS as follows:
 diff -u -r1.13 backend_ps.py
 --- backend_ps.py 13 Nov 2004 11:41:54 -0000 1.13
 +++ backend_ps.py 19 Nov 2004 16:23:13 -0000
 @@ -529,10 +529,7 @@
		 basename, ext =3D os.path.splitext(outfile)
		 if not ext: outfile +=3D '.ps'
		 isEPSF =3D ext.lower().startswith('.ep')
 - try:
 - fh =3D file(outfile, 'w')
 - except IOError:
 - error_msg_ps('Could not open %s for writing' % outfile)
 + fh =3D file(outfile, 'w')
		 needsClose =3D True
		 title =3D outfile
Slight problem: it might now be a little bit more difficult to include
the name of the file which could not be opened in the error message.
The IOError exception will probably only have "permission denied" associated
with it.
All the best,
Jochen
--=20
http://seehuhn.de/

>>>>> "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

On Thu, 2004年11月18日 at 18:05 +0000, Jochen Voss wrote: 
> 4) some ideas:
> 
> - The backends could return errors via python standard exceptions
> without printing messages and such. This leads to simple code,
> feels quite Pythonic, makes the backends more independent of the
> error reporting policy and at the moment seems to be the only sane
> solution to me.
> 
> - The backends should have a function which the matlab interface can
> call to report errors to the user. This should pop up a dialog
> etc. on GUI backends and just print the message to stderr for
> non-GUI backends. It should not terminate the program.
I agree with these ideas.
> 7) Conclusions:
> 
> I suggest the following.
> 
> - Change backend_template.py and all the other non-GUI backends to
> 
> 	def error_msg_ps(msg, *args):
> 	 """
> 	 Signal an error condition.
> 	 """
> 	 sys.stderr.write('Error: %s' % msg)
I'd prefer to merge error_msg into the Verbose class, or just delete it.
> - Change all callers of error_msg to terminate the program after the
> call when appropriate
Agree
> - Remove the verbose.report_error function and replace it with Python
> exceptions etc.
Agree
> What do you think?
At the moment we have error_msg(), the Verbose class and exceptions all
working in the same area and a bit of confusion as to which one does
what. I don't think we need all three. 
I suggest
- using exceptions to handle errors that may terminate the program, and
allowing the matlab interface, GUI backends and user scripts to catch
these exceptions.
- using verbose for all reporting
- merging error_msg() into the Verbose class (with the GUI backends
possibly subclassing Verbose to provide a popup error dialog)
Steve