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

[Mike Emmel]

Well so far its always been the current path problem.
I have a patch for cairo_get_current_point that allows the user to
guard agianst it.
But my main question is why would the path ever not be defined.
I think it should always go back to a moveto 00 by default.
We already have a boolean that can flag if the user never set the path.
So the error of a unset path should only ever be returned by cairo
current point.

That is my biggest gripe right now.

Other errors that may not be fatal

CAIRO_STATUS_SURFACE_TYPE_MISMATCH
CAIRO_STATUS_PATTERN_TYPE_MISMATCH
CAIRO_STATUS_INVALID_FORMAT
CAIRO_STATUS_INVALID_VISUAL
CAIRO_STATUS_INVALID_DASH

Now I'm just looking at them to see if it makes sense that they are a error.
In most cases these are return values and don't set the status flag.
Which is the right thing IMHO. But  CAIRO_STATUS_SURFACE_TYPE_MISMATCH
is does set status.
I think this is a recoverable situation and should not cause a error.
Just grepping for it through the code sometimes it seems to be returned
and sometimes it sets cairo status so the use may be inconsistent.

In any case you need to do a serious audit I just did a bit of grepping.

Just looking at the code the use of cairo_status_t as a return value
and setting it to make the cr in error is not consistent in general.








On 9/22/06, Carl Worth <cworth at cworth.org> wrote:
> 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
>
>
>