[Xcb] problem with the use of the shm extension

[Carl Worth]

On Mon, 17 Oct 2005 22:58:05 -0400, Trevor Woerner wrote:
> A user can write code that looks like:
> 
> 	cairo_moveto (cr, x, y);
> 	cairo_lineto (cr, x1, y1);
> 	cairo_set_source_rgb (cr, r, g, b);
> 	cairo_fill (cr);
> 	if (cairo_status (cr) != CAIRO_STATUS_SUCCESS) {
> 		error ();
> 	}
> 
> Which is considered easier to read.

Yes, that's the general idea behind cairo's error-handling strategy.

There's a related piece which is that object-creating functions don't
return NULL. If an error occurs during object creation a pointer to a
static "nil" object (initialized with a non-success status value is
returned).

The existing status checks that turn most functions into noops handle
most cases of the nil objects. But there are a few functions that need
special treatment. For example, functions that manipulate the
reference count of an object are not noops for a non-success status of
a "real" object, but they must be a noop for a "nil" object. We give
nil objects a reference count of -1 for this purpose.

The nil object isn't perfect, as it has led to some bugs in usage. For
example, we've run into users who _do_ add checks for NULL that end up
not working at all. For example, the following code appears to be
checking for an error, but will actually continue in spite of the
error:

	surface = cairo_image_surface_create_from_png (filename);
	if (! surface)
	    error (); /* file not found? out of memory? */

The corrected code turns out to be a bit more verbose, (which is
against the overall spirit of the strategy), but does allow for more
specific information on what kind of error occurs:

	surface = cairo_image_surface_create_from_png (filename);
	if (cairo_surface_status (surface))
	    error (cairo_surface_status (surface));

Where here the return value of cairo_surface_status can be used to
distinguish CAIRO_STATUS_FILE_NOT_FOUND from CAIRO_STATUS_NO_MEMORY.

I still regard cairo's error-handling strategy as an experiment, but
it seems to be a mostly successful experiment so far.

Oh, the fact that everything shuts down after an error, and there's no
way to clear an error except to create a new context object, has been
the source of some annoyance to the Mozilla-SVG folk. They're trying
to render as much of a document as possible, so it causes them some
pain that if a document contains an error, (say, a non-invertible,
all-zero matrix), that the cairo_t object shuts down from then on.

Sorry if that's a bunch of off-topic rambling. Maybe there's something
useful there for you.

-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/xcb/attachments/20051018/c6d57b12/attachment.pgp