[Xcb] XCB error handling; my ultimate proposal

[Jamey Sharp]

On Thu, Dec 29, 2005 at 07:05:32PM -0800, Barton C Massey wrote:
> In message <20051228211809.GI8079 at id.minilop.net> you wrote:
> > Should it really be considered a programming error to pass a
> > non-null pointer to *Reply on a cookie used with *Blind? I
> > believe I mentioned in a previous e-mail that it would be nice
> > in generic code like the xcb_reply library to be able to get
> > the error if it was kept out of the event queue, without
> > caring which kind of cookie it has.
> 
> AFAIK this is precisely the thing you can't have?  If you're
> allowed to pass a non-null pointer to a *Blind *Reply (uggh)
> I can't tell whether to put the error into the event queue
> until I've seen the *Reply.

I'm not suggesting any change in behavior from your proposal, except to
remove the assert. If the cookie was blind, then whether you pass in a
pointer to *Reply or not you'll never get an error back that way --
it'll always wind up in the event queue. This seems harmless: you'll
have error-handling code in places where no error can occur.

> > You really want current code to entirely discard errors?
> 
> I'm indifferent.  The current situation, in which it
> silently discards some but not all errors depending on
> timing, seems like the worst of all worlds. :-)

(XCB never discards an error currently, FWIW. The app always has to
retrieve and then free it, or let all the memory be cleaned up by a call
to XCBDisconnect.)

> > For consistency of semantics and names, how about using
> > *RequestChecked and *Request for both void and non-void
> > requests?
> 
> Obviously I thought about this a bit before proposing the
> wacky naming I did. :-) I think on balance I'm not too
> concerned about naming consistency---IMHO it's not that
> confusing.  The advantage of what I proposed is that the
> default names (without a Blind or Check suffixes) correspond
> to my recommended programming practice for simple
> programs. :-)

OK, now I'm kind of torn. I like naming consistency between void and
non-void requests -- I think making unnecessary distinctions between
them is pretty arbitrary. But I'll have to think about whether I agree
that simple apps should handle non-void errors inline while deferring
void errors to the event queue. Could you give me some rationale for
that recommendation?

--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/20051231/dcf007be/attachment.pgp