[Xcb] XCB error handling; my penultimate proposal

[Vincent Torri]

On Sun, 18 Dec 2005, Barton C Massey wrote:

> Actually, (1) isn't what the APIs describe now, although
> it's close.  If we were to make the current API do (1), then
> applications that didn't check *Reply() for null on *every*
> request would lose, and you would still have to put an error
> handler in the event loop to handle errors from non-reply
> requests.
>
> So Keithp's proposal (4) is that we do the above; if
> desired, we can extend with a bunch of *Nerr() requests ala
> my proposal (3) later to get Jamey's functionality.
>
> Comments?  Especially from someone other than the three of
> us?

i'm trying to port ecore to xcb and to use the properties of xcb
correctly (I've sent an example but no one made comments on it) and I use
the fact that all the reply functions has the same prototype:

XCBConnection *, unsigned int, XCBGenericError **

I don't know if my method is good or not, but i think that xcb has to
manage a bunch of reply asks in a easy manner. Otherwise, it will be
*really* a pain. I don't know what to do yet, if I can't have the same
prototype for all the reply functions.

my 2 cents :)

Vincent

>
> 	Bart
>
> In message <1134963912.8789.4.camel at evo.keithp.com> you wrote:
> >
> > --=-smV1m+VK5dvK0/5QTcys
> > Content-Type: text/plain
> > Content-Transfer-Encoding: quoted-printable
> >
> > On Sun, 2005-12-18 at 09:32 -0800, Barton C Massey wrote:
> >
> > > Of course, my favorite is alternative 3: "let's do both!"
> >
> > I suggest that we can implement 1) now (it's what the API looks like)
> > and see if anyone finds reasonable uses for 2), at which point we can
> > add it using Bart's suggested APIs.
> >
> > While the uniform behaviour of always processing errors through the
> > normal event loop is appealingly symmetrical, I'm afraid I haven't seen
> > any substantive use cases where this is better than returning errors
> > where the reply would have been, and there are plenty of examples where
> > returning the error precisely where the reply would have been makes
> > things far easier.
> >
> > We can obviously add Bart's APIs in a later release; I only suggest that
> > we hold off until we find a compelling reason to extend the library in
> > this fashion.
> >
> > -keith
> >
> >
> > --=-smV1m+VK5dvK0/5QTcys
> > Content-Type: application/pgp-signature; name=signature.asc
> > Content-Description: This is a digitally signed message part
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.2 (GNU/Linux)
> >
> > iD8DBQBDpizHQp8BWwlsTdMRAnjBAJ4vGdwLtqyxJb5qlbYXU6GzKBrUfQCgpfEY
> > 5gUxWg4Bs2RbWxNKSTPtkjU=
> > =XGu8
> > -----END PGP SIGNATURE-----
> >
> > --=-smV1m+VK5dvK0/5QTcys--
>
>