[cairo] error handling

[Baz]

On 29/05/07, Behdad Esfahbod <behdad at behdad.org> wrote:
> On Sat, 2007-05-26 at 19:47 -0400, Baz wrote:
> > The manual says ' Errors propagate from object
> > to object. Setting a pattern in an out-of-memory state as the source
> > of a cairo_t puts the type into an error state....Much of the above is
> > not yet implemented at the time of this writing'
>
> Where does it say so in the manual?  We should remove it as error
> handling is pretty much implemented these days.

http://www.cairographics.org/manual/bindings-errors.html

> As for the issue you raise, it has been discussed in the past, in
> response to the text-glyph-range test that you added to the test suite.

Yeah...I remembered having the problem before but couldn't remember
where it went wrong :)

> With the freetype backend that test causes invalid memory accesses with
> the PDF backend currently, and is marked XFAIL in the test suite until
> we get to clean the mess up.  I tried to do that before a release but it
> wasn't quick and easy.
>
> As for the resolution, I believe that an invalid glyph index should not
> put a cairo_t (or cairo_scaled_font_t) into an error status.  One way to
> make this work may be to change signature of all public functions taking
> glyphs to return a cairo_status_t.  We have discussed whether such
> changes are allowed in the past and the conclusion was that this is
> fine.  So, seems like all that is missing is for someone to go and
> implement this.  May as well return a similar error from
> cairo_show_text()/cairo_text_path() if no glyph is found for at least
> one character in the input text.
>

There's two problems here: the scaled font was in an error state, and
that didn't propogate to the cairo_t; and the scaled font was in an
error state for no good reason, we should have returned a status_t
instead. The first problem is something we should just fix, right?

The policy on when to return a status_t is bit vague though. I can
understand a policy where operations that shouldn't affect cairo's
state fail this way - this is what's happened to the getters, and
would work for glyph_extents, text_extents, text_to_glyphs. I see less
distinction between a failure in cairo_text_path and, say,
cairo_append_path though?

Oh while we're at it - get_current_point should return a status_t too
:) (I think this has been discussed before)

I'll work up some patches to give us something more concrete to look at.

Cheers,
Baz