[cairo] Refreshing the error semantics

Chris Wilson chris at chris-wilson.co.uk
Mon Jan 26 14:08:20 PST 2009


Hello all,
Jeff Muizeilaar posed a problem recently on IRC querying why the
font-face was being put into an error condition on calling
cairo_scaled_font_create().

The principle behind Cairo's error handling system is that when an error
occurs we assume the worst, fear that the object has been left in an
inconsistent state and so mark that object as inert so that we never
reference it again. This leads to a robust library with very clean error
semantics that are in keeping with its minimal API.

The situation that Jeff was concerned about was that the font-face was
being left in an error simply because we failed to allocate the scaled
font, or even because the user passed in an invalid matrix. The latter
is quite obviously a mistake - a missing guard in the public API.
However the former implies distinguishing between (fatal) error
conditions that merely affect this particular call, e.g. an allocation
failure, versus those for which we must presume the worst and shutdown
the parent object - for example, these could include detection of a
corrupt font file, or a locking error. In this case, Jeff identified
that we could use the return value of the backend call to
scaled_font_create() to identify a fatal backend error and allow the
callee to simply create an nil-scaled-font for any error that should be
passed back to the user without shuting down the font-face.

I've attached the 3 patches that convert cairo-scaled-font.c and
cairo-ft-font.c over to this more subtle semantic and I look forward to
the discussion!
-ickle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0024--scaled-font-Guard-against-invalid-matrices-when-cr.patch
Type: text/x-patch
Size: 0 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20090126/ee86f384/attachment.bin 


More information about the cairo mailing list