[cairo] On recovery from errors in cairo (was: cairo reset)

[Carl Worth]

On Fri, 22 Sep 2006 08:49:19 -0700, "Mike Emmel" wrote:
> > >
> > To add to this cairo issues a number on non fatal errors esp ones about the path
> > not existing there is no way to reset cairo_status_t if you can handle
> > the problem
> > i.e. catch the error and continue. Once cairo_status_t is set your dead.
> > In general there seem to be systematic problems in the code with operations
> > that can be performed without a path and those that require a path.
> > By sys
> >
> Sorry accidently sent.
> By systematic I mean its not clear without careful reading of the docs which
> methods can be performed without a path set.

Can you describe what "path not existing" problems you've run into?

If people are seeing cairo do its shutdown-on-error thing in annoying
ways where they would have preferred to easily recover, then we should
fix that. I think there's a pretty clear strategy for doing that:

1. If cairo considers something an error where it could instead behave
   in a way that is consistent with the defined semantics of the API,
   then this is a bug that should just be fixed in cairo.

   Example: Imagine cairo_fill is setting an error when there is no
   path set. The defined semantics of an empty path are quite clearly
   that cairo should draw nothing, so it should just do that and not
   set the error.

2. If the user is asks cairo to do something that has no reasonable
   interpretation, then it is legitimate for cairo to set a permanent
   error.

   Example: Calling cairo_transform with a non-invertible matrix puts
   cairo in a situation where it cannot continue and implement the
   defined semantics of cairo_transform. So cairo will set an error in
   this case.

3. In every error of class 2, cairo must provide means for the user to
   determine in advance if an operation will be able to succeed, so
   the user can avoid the error before it happens.

   Example: Before calling cairo_transform, the user can call
   cairo_matrix_invert, (only necessary if the user doesn't already
   know that the matrix is invertible), and avoid calling
   cairo_transform with an illegal matrix.

Basically, allowing users to avoid committing errors is a strategy much
more likely to yield a reliable implementation rather than trying to
allow the user to commit any error and also allow recovery from all
errors.

I can imagine that there are bugs in cairo of class 1, (where cairo is
setting an error when it should simply implement a well-defined
operation), or of class 3, (where cairo does not provide a means to
query in advance if an operation will be legal).

But I don't recall any knowledge of such bugs currently. So if you
know of any, please provide some details so that we can fix them.

And if anybody can see some flaws in the strategy outlined above, I
would love to hear that kind of feedback too.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20060922/78e33f59/attachment.pgp