Foutafhandeling in Xlib
Waarom een X-programma kan sneuvelen door een fout in een verzoek van twintig aanroepen eerder, en wat XSetErrorHandler en -sync daaraan doen.
Xlib buffert zijn verzoeken en wacht niet op antwoorden tenzij het moet. Wijst de server er een af – BadWindow voor een venster dat al is vernietigd, BadMatch voor een pixmap met de verkeerde diepte, BadAccess, BadAlloc, BadValue – dan komt de fout lang na de veroorzakende aanroep als gebeurtenis terug. De standaardhandler drukt 'X Error of failed request' af met de foutcode, de opcode (Major opcode 20 (X_GetProperty)), de resource-ID en twee serienummers, en beëindigt dan het programma. De serienummers zijn de aanwijzing: het nummer van het mislukte verzoek tegenover het huidige laat zien hoever men achterloopt.
XSetErrorHandler installeert een eigen handler, en vrijwel elke windowmanager doet dat, omdat een client zijn venster kan vernietigen tussen het moment dat de manager ervan hoort en het moment dat die handelt; die race is niet te winnen, alleen te negeren. XSetIOErrorHandler dekt het andere geval, een verbroken verbinding, waaruit geen terugkeer mogelijk is. Voor debuggen laat XSynchronize of de Xt-vlag -sync elk verzoek op zijn antwoord wachten, zodat de fout bij de juiste aanroep terechtkomt en een breakpoint op _XError in gdb laat zien waar; de prijs is een rondreis per verzoek. XCB bouwde het model om: fouten komen terug als antwoord op het verzoek dat ze veroorzaakte, op te halen met xcb_request_check of uit de gebeurtenissenrij, en er is geen globale handler die men kan vergeten te installeren.