matplotlib-devel Mailing List for matplotlib

John Hunter schrieb:

> try : save_ps(fname)
> except IOError, msg:
>    verbose.report_error('Backend PS failed to save %s'%fname)
>    raise IOError(msg)

Just 'raise' is enough, python by default will re-raise the original exception 
untouched.

I'll leave this discussion to you guys, I don't know the matplotlib code 
enough to contribute anything really useful.  My only point is that reusing 
SystemExit for other purposes, with additional information encoded in the 
message, is IMHO a bad idea.  There's a reason why exceptions make up a class 
hierarchy: this allows you to use classes for the flow control mechanisms, 
leaving the string messages simply as additional information mainly for the 
user.  Since these messages are potentially locale-sensitive, and can change 
over time (spelling, capitalization, etc), it's just not a good idea to base 
code behaviour on them.

Cheers,

f

Hello,

I tried to think a little bit more systematically about the way
error conditions and messages are passed around in matplotlib.

1) There see to be several kinds of object:

  - informational messages like the output of --verbose-debug-annoying
  - error messages which the matlab interface passes to the
    backends to have them displayed to the user
  - error conditions reported by the backends to the caller

2) Typical scenarios:

  a) A user tries to debug some installation problem by using
     the --verbose-debug-annoying option or similar.  This generates
     potentially a lot of messages which should shown to the user.
     Dumping them all to stdout or stderr seems fine here.

  b) A script calls the matlab interface functions with invalid arguments.
     The user should get an error message.  In a GUI backend this error
     message might pop up in a message window or similar.

  c) A backend encounters an error condition, e.g. if it cannot open
     the file, cannot load a font etc.  If a GUI backend is active
     the error message should be displayed by the GUI backend,
     otherwise it should be printed to stderr or similar.

Is this so far correct?

3) Required or almost required properties of the implementation:

  - the user should be able to customise how much information he
    sees, e.g. by using the --verbose-* options

  - The GUI backends should not be terminated if there is an error
    while saving a file etc.

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.

    Rationale for not calling verbose.report_error in this function:
    the GUI backend reports the error on its own (dialog, status line,
    etc), so it does not need to use verbose.report_error
    additionally.  When the PostScript backend is called from the GUI
    backend, then the GUI backends error report function will be used,
    what PostScript does does not matter.  In all other cases
    displaying the error message to stderr seems the only useful thing
    to do (e.g. disabling it is not useful).

5) the verbose.report mechanism:

  At the moment I am not sure how this fits in here.  Maybe it should
  only be used for non-error messages?

  What is configurable here?  The user can choose the amount of
  messages he wants to see.  Anything else?

6) Analysis of the three scenarios above:

  a) --verbose-* output:

     Here the flow of control is straightforward.  At random places
     there are calls to verbose.report.  These are either discarded
     or printed to stdout.  This is currently done by the Verbose class.

  b) invalid arguments

     Again, this is simple: the matlab interface calls error_msg,
     the GUI backend does something useful with the message.

  c) backend error conditions

     This seems to be the most complex scenario.  I think this should
     work as follows: the backend raises the standard Python exception,
     e.g IOError.  If the GUI backend calls the PostScript backend,
     it should catch any exception from the PostScript backend call,
     and tell the user about it.

     If the user in a script calls e.g. "savefig('/fig1.eps')" and has
     no write permission for the root directory, then he will get the
     Python exception and can do with it whatever he likes.

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)

    Maybe even make this function a class method of the
    FigureManagerBase class?  (the "error_msg =3D error_msg_..."
    assignments seem hackish.)

  - Change all callers of error_msg to terminate the program after the
    call when appropriate

  - Remove the verbose.report_error function and replace it with Python
    exceptions etc.

What do you think?

Jochen
--=20
http://seehuhn.de/

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

Hello John,

On Thu, Nov 18, 2004 at 10:24:57AM -0600, John Hunter wrote:
> I suggest we rework the image backends to not define an error message
> function at all, but simply to import and reuse the one from
> backend_bases.  This will make it easier to change the policy in a
> single place.  Secondly, an image backend should never call this
> function, it should be reserved for the matlab interface simply to
> insure a consistent interface between the various backends.
Sorry, I am still not clear about this function.  What is its purpose?
When will it be called?

> Thirdly, the image backends should verbose.report/report_error where
> appropriate, and raise when indicated.  GUI backends can catch these
> exceptions and handle them how they want.
This sounds fine for me.

All the best,
Jochen
--=20
http://seehuhn.de/

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:


    Steve> I tried this calling the SVG backend directly and by
    Steve> switching to the SVG backend from the GTK backend and it
    Steve> works OK.

This gets back to our previous unresolved discussion on error handling
in the image backends.  I think the way it is done now is a historical
accident.  In the olden days, pre matplotlib-0.50, there was no
ability to switch backends, or to use an image backend within a GUI
(eg gtkcairo, gtkagg).  So the image backends were free-standing and
their error handling didn't have much impact outside their own scope.
Now they clearly do.

The second design problem was that I preferred simple error messages
rather than exceptions with tracebacks.  This grew out of my
experience with users of my GUIs who basically will not read a
traceback - they appear to have blinders on.  However, they will read
a simple message like

  Could not save file blah, blah, blah.

But as we are seeing, this approach (simple message, SystemExit)
doesn't scale well and isn't appropriate when GUIs are calling image
backends.  

I suggest we rework the image backends to not define an error message
function at all, but simply to import and reuse the one from
backend_bases.  This will make it easier to change the policy in a
single place.  Secondly, an image backend should never call this
function, it should be reserved for the matlab interface simply to
insure a consistent interface between the various backends.  Thirdly,
the image backends should verbose.report/report_error where
appropriate, and raise when indicated.  GUI backends can catch these
exceptions and handle them how they want.

In the case at hand, it might be sensible for backend ps to catch an
IO Error, report to verbose report_error, and then rethrow the error
with the message.  Something like

try : save_ps(fname)
except IOError, msg:
   verbose.report_error('Backend PS failed to save %s'%fname)
   raise IOError(msg)


Thoughts?

JDH

Hello Steve,

On Thu, Nov 18, 2004 at 11:38:10PM +0800, Steve Chaplin wrote:
> At the moment the PS backend does
>   try:
>       fh =3D file(outfile, 'w')
>   except IOError:
>       error_msg_ps('Could not open %s for writing' % outfile)
>=20
> which translates into
>   try:
>       fh =3D file(outfile, 'w')
>   except IOError:
>       verbose.report_error('Error: Could not open %s for writing' %
> outfile)
>       sys.exit()
>=20
> The backend does not do any cleanup after the exception, so I think it
> could be changed to just
>       fh =3D file(outfile, 'w')
As I understood John, the plan is to report error messages via the
verbose.report_error function.  Where would this be called with
the modified code (especially when there is no GUI backend active)?

> allowing the exception terminate the program with the error message
> appearing at the end of the traceback.
This looks really ugly to me.  But maybe it is the script author's
responsibility to catch this if he cares about this.

> Then the GUI backends can then do
>     from backend_svg import FigureCanvasSVG as FigureCanvas
>     try:
>         fc =3D self.switch_backends(FigureCanvas)
>         fc.print_figure(filename, dpi, facecolor, edgecolor,
> orientation)
>     except IOError, exc:
>         error_msg("%s: %s" % (exc.filename, exc.strerror), parent=3Dself)
What about other exceptions thrown by the backend?

I see that passing the original exception to the caller is cleaner
and I would be happy to change the PostScript backend to do this.
The only question for me is: how and when is the "report_error" function
to be used?

All the best,
Jochen
--=20
http://seehuhn.de/

On Wed, 2004-11-17 at 10:54 -0700, Fernando Perez wrote:
> Jochen Voss schrieb:
> > Hello Steve,
> > 
> > On Wed, Nov 17, 2004 at 11:00:32PM +0800, Steve Chaplin wrote:
> > 
> >>I don't think failure to save a file should be a fatal error.
> >>Perhaps PS/SVG print_figure() could raise an exception for the GUI
> >>backend to catch so it can popup an error message and continue.
> > 
> > Even now you can probably (not tried) catch the SystemExit
> > exception and prevent the program from aborting.
> > Do you think raising SystemExit like
> > 
> >     raise SystemExit("error while writing file: permission denied")
> > 
> > would be good enough.  The GUI frontend could catch SystemExit,
> > check whether the associated value is a string, and then display
> > this string in an error message box.
> > 
> > What do you think?
> 
> Bad design.  Doing exception analysis based on string matching for the message 
> is very brittle.  A single change in capitalization of the message can break 
> things down the road.
> 
> It's _far_ better to either:
> 
> 1. have the ps/svg backends do whatever cleanup they want, and then reraise 
> the original exception unchanged
> 
> 2. or simply make a matplotlib.SaveError exception which can be explicitly 
> caught based on class matching, which is the preferred python way of doing this.
> 
> Best,
> 
> f
At the moment the PS backend does
  try:
      fh = file(outfile, 'w')
  except IOError:
      error_msg_ps('Could not open %s for writing' % outfile)

which translates into
  try:
      fh = file(outfile, 'w')
  except IOError:
      verbose.report_error('Error: Could not open %s for writing' %
outfile)
      sys.exit()

The backend does not do any cleanup after the exception, so I think it
could be changed to just
      fh = file(outfile, 'w')
allowing the exception terminate the program with the error message
appearing at the end of the traceback.

Then the GUI backends can then do
    from backend_svg import FigureCanvasSVG as FigureCanvas
    try:
        fc = self.switch_backends(FigureCanvas)
        fc.print_figure(filename, dpi, facecolor, edgecolor,
orientation)
    except IOError, exc:
        error_msg("%s: %s" % (exc.filename, exc.strerror), parent=self)

I tried this calling the SVG backend directly and by switching to the
SVG backend from the GTK backend and it works OK.

Steve

Hello,

On Wed, Nov 17, 2004 at 10:54:49AM -0700, Fernando Perez wrote:
> Bad design.  Doing exception analysis based on string matching for the=20
> message is very brittle.  A single change in capitalization of the messag=
e=20
> can break things down the road.
Sorry, maybe I was not clear enough.
What I tried to suggest was:

1) GUI backends should catch the SystemExit exception from the PS backend,
  thus being able to continue running even if the backend aborts with an
  error.

2) GUI backends should in case that they caught a SystemExit exception
  notify the user that saving the figure as PostScript failed.  If
  the exception is associated with an error message string, they could
  display this string to the user.

> 1. have the ps/svg backends do whatever cleanup they want, and then rerai=
se=20
> the original exception unchanged
>=20
> 2. or simply make a matplotlib.SaveError exception which can be explicitl=
y=20
> caught based on class matching, which is the preferred python way of doin=
g=20
> this.
Maybe.  But how is any information except "the backend failed with
error message ..." useful to the GUI?  Would it act differently on
an font-not-found condition then it would on a save-failed one?

All the best,
Jochen
--=20
http://seehuhn.de/