[Xcb] XCB error handling; my ultimate proposal

[Barton C Massey]

In message <20051228211809.GI8079 at id.minilop.net> you wrote:
> On Fri, Dec 23, 2005 at 10:06:55PM -0800, Barton C Massey wrote:
> Just for the record I'd like to point out that everywhere you
> said "two-argument *Reply", I'm pretty sure you meant the
> current three-argument *Reply functions.

Yes. :-)

> >   For every request expecting a reply:
> >     Provide a *RequestBlind() version of the request that
> >     defers errors to the event queue.  Retain the
> >     two-argument *Reply() function.  For *Request(), if the
> >     second argument is not a 0 pointer, it is filled in with
> >     the error record.  Otherwise, the error record is
> >     discarded.  For *RequestBlind(), the second argument to
> >     *Reply() must be a 0 pointer (else an assertion
> >     failure), and any error records are put in the event
> >     queue.
> 
> 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. :-)

> Is "Blind" the best choice of name? I don't have any
> alternatives...

I take it an alternative is suggested below.

> 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.  This means that the error would
arrive out-of-sequence, and might not arrive at all if
*Reply was never called.  Am I missing something?

> >   For every request not expecting a reply:
> >     Provide a *RequestChecked() version of the request that
> >     keeps errors out of the event queue.  If a
> >     *RequestChecked() was issued (and returned a non-zero
> >     sequence number), the application is responsible for
> >     calling
> >       XCBGenericError *XCBRequestCheck(XCBVoidCookie c)
> >     at some point; this will sync the connection up to the
>     given sequence number and return 0 if the request
> >     succeeded else a pointer to the error, which will not
> >     appear in the event queue.  Failure to call
> >     XCBRequestCheck() when needed is essentially a memory
> >     leak.  For the unchecked *Request(), any error will
> >     appear in the event queue, and a call to
> >     XCBRequestCheck() will cause an assertion failure.
> 
> For consistency of semantics and names, how about using
> *RequestChecked and *Request for both void and non-void
> requests? The impact on existing code is a little bit higher
> that way, but as you've observed this functionality isn't
> widely used right now...

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. :-) Anyone writing a window manager or something
else big and fancy that wants to do Jamey's style of error
checking will have to remember that non-void requests become
blind and some void requests become check, but those folks
can fend for themselves. :-)

    Bart