[Xcb] XCB error handling; my ultimate proposal

[Barton C Massey]

In message <20051231200130.GG9451 at id.minilop.net> you wrote:
> 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.

It just seems like the programmer has likely made a mistake
at this point, and would like to be notified.  Statically
would be better, but I don't *think* we want to go as far as
having the two kinds of requests have different cookie types
and passing the cookies to different reply functions.  I
dunno, maybe we should.

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

Just that it's what everyone does (in the best case) anyway.
One *has* to check whether an error occurred for non-void
requests, because the reply pointer will be null.  Folks can
never seem to be bothered to check errors on void requests,
so at *best* they can be picked up in the event handler.

    Bart