[Xcb] bug #8208: handling fatal or semi-fatal errors

[Jamey Sharp]

I forgot these points:

This is only a blocker for a 1.0 release if the behavior change would
break existing applications. For example, if a program tests the
returned XCBConnection for null, but doesn't test reply pointers for
being null, then after the proposed behavior change it would segfault on
connection failure rather than handling it cleanly. (However, such a
program is buggy anyway.)

In another example: A program might reasonably be able to recover from
certain kinds of failures to issue requests (e.g., RenderTrapezoids, on
a server without RENDER, or with a very large list on a server without
BIG-REQUESTS). Under the current behavior, the program can guess what
might have gone wrong and try a fallback path; under the proposed
behavior, the XCBConnection gets shut down and fallbacks will always
fail too. Bart and I believe this is OK because the application could
have checked first whether RENDER was available and how large of a
request it can issue, and choose to fall back without trying a request
that will fail. But it means that programs written in this backwards way
would break under the changed behavior.

I can't actually think of any case where a reasonable program would
break with the proposed behavior change, so we could choose to specify
these interfaces so that either behavior is allowed, and leave the
current behavior in place for the 1.0 release. That would reduce our
testing burden.

Choosing the Cairo-like behavior might give us the opportunity to
simplify error handling throughout the API, though. We should study
whether that's true: it would be a strong argument in favor of making
this change now. But I'm inclined to do it regardless, as it should be
at least a small aid to developers.

--Jamey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/xcb/attachments/20060912/a63e412b/attachment.pgp