[Xcb] [Bug 78140] The tutorial should have a section on error handling

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Thu May 1 08:38:57 PDT 2014


--- Comment #3 from Uli Schlachter <psychon at znc.in> ---
(In reply to comment #2)
> I should be able to put together at least a prototype myself but I need to
> ask a few more questions.

Thanks a lot!

> Do I need to call xcb_connection_has_error after absolutely every function
> that gets passed a connection?

Nope. Nothing bad happens when you use an xcb_connection_t that is an error
state. Must functions will just return e.g. NULL (however, no one ever expects
e.g. xcb_get_setup() to return NULL, so other code can still crash...).

> Is there a function to get an error string for each error (keep in mind that
> one may want to sometimes localize error messages so this is not as easy as
> it seems).

Nope, and I wouldn't want to add one exactly because of things like
localization. I guess you are expected to write your own function that
translates the ~5 error codes that are currently in-use into a string and that
returns something like "unknown error 42" for other values.

E.g. qt does the following:

> How do I check for errors with the xcb_disconnect function (I know that
> free(3) does not give errors but what about close(2))?

There just are no errors. :-)
Also, there aren't many sensible things that can be done if close(),
pthread_mutex_destroy() or pthread_cond_destroy() fail (AFAIR on some systems
close() can fail and still have closed the FD already, so retrying would be
unsafe in multi-threaded programs anyway).

So if any errors occur during xcb_disconnect(), you'll get a memory / file
descriptor leak.

You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/xcb/attachments/20140501/ea4b6e6b/attachment.html>

More information about the Xcb mailing list