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

[Jamey Sharp]

Currently, when XCB can't issue a request, the library returns a reply
cookie with a sequence number of 0. If you try to force such a cookie,
you'll get a null reply pointer and a null error pointer. There are
several possible reasons why a request could fail to be issued, though,
and we give absolutely no hint about what went wrong. (A related issue
is that when XCBConnect fails, the application can't find out why.)

Bart argues that this is bad. :-) He suggested to me (I'm interpreting
somewhat liberally) that we follow an error handling model similar to
Cairo. If a serious error occurs that either is fatal or the application
could have prevented, then the XCBConnection object shuts down and all
further operations on it fail. The XCBConnection can then be queried for
more details about what error occurred. This might mean that XCBConnect
never returns null, but can return various kinds of error objects.
	http://www.cairographics.org/manual/cairo-Error-handling.html

For reference, I think Xlib provides no hints in this area. XOpenDisplay
gives the application no information on connection failure; I/O errors
always cause exit() to be called; and error handling on implicitly
generated requests is ad-hoc. We're currently doing as well as or
slightly better than Xlib, and anything we do will be an improvement.

I propose that we adopt the behavior that serious errors shut down the
XCBConnection, and that connection failure returns an error object
instead of a null pointer. However, in the interests of getting a stable
release out in four days, I'd like to add as little new API as possible
to support this behavior. Callers need to be able to determine if
they've gotten an error object from XCBConnect, but otherwise I think
this behavior is compatible with all current callers' expectations.

I suggest that this minimal new API resemble the cairo_status function
and the cairo_status_t enumeration; and that the enumeration have only
SUCCESS and UNKNOWN_FAILURE or some such. I suggest not yet adding an
equivalent of cairo_status_to_string. Further enumeration values and
more detailed error querying functions can follow later.

Any objections?

--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/0aa63b81/attachment.pgp