Uhm. Error replies from the server should be explained sufficently, I guess (the whole deal with "checked vs unchecked errors").

For out of memory errors or I/O errors, the xcb_connection_t goes into an error state. All function calls with it will fail and xcb_connection_has_error() can tell you which error occured (there are some defines in xcb.h with a XCB_CONN_ prefix).

XCB never calls exit().

Would it be too much work for you to create a patch for the tutorial that adds what you would have wanted to know? It should be available in git at https://secure.freedesktop.org/cgit/xcb/ and clonable fromgit://wiki.freedesktop.org/wiki/xcb.

Okay, this was confusing for me. There is no section in the tutorial but there is somewhat of an explanation on error handling in the xcb-requests.3 man page (it doesn't mention the xcb_connection_has_error part though).

So, my bug should now be: add a section on error handling to the tutorial, copy some parts of the xcb-requests.3 man page to the section and add information on handling client errors with xcb_connection_has_error.

I should be able to put together at least a prototype myself but I need to ask a few more questions.
Do I need to call xcb_connection_has_error after absolutely every function that gets passed a connection?
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).
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))?

(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:
https://qt.gitorious.org/qt/qtbase/source/d52b00e1d3cc60c81b54a89d6da488dc4bbce384:src/plugins/platforms/xcb/qxcbconnection.cpp#L95-126

> 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.

I find it unfortunate that xcb_disconnect does not return an error code.

First of all, the close and EINTR problem is easily solvable. Simply, block all signals while closing a file and then the EINTR error can never happen.

Second of all, an obvious thing to do if close fails in a process is to exit the process and disable that part of the system but keep the rest of the system running (that way someone can run a debug console later on and diagnose and fix the problem or recover data if the system is truely broken). Simply going on instead is wrong because that might result in corrupting user data. I'd even rather have the function abort on errors then simply ignore them.

Thirdly, pthread_mutex_destroy and pthread_cond_destroy should not fail with  errors on proper use of their functionality so they are irrelevant.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/proto/xcbproto/issues/11.