[cairo] error handling questions

Travis Griggs tgriggs at cincom.com
Thu Jul 5 09:29:13 PDT 2007


On Jul 5, 2007, at 7:08, Carl Worth wrote:

> On Thu, 05 Jul 2007 11:01:00 +0100, Bill Spitzak wrote:
>> Depending on the error this could be pointers to string constants  
>> (this
>> would be a requirement for out-of-memory), or a buffer allocated and
>> belonging to the cairo_t. I would think some function would be  
>> used to
>> retrieve the error:
>>
>> const char* cairo_error_string(cairo_t);
>
> That's been there for a long time, (and it does return a pointer to a
> string constant). See:
>
> 	const char *
> 	cairo_status_to_string (cairo_status_t status);

The problem is that backend specific errors don't work their way into  
this system. I.e. you can't use this mechanism to report that win32  
produced some esoteric error when you did a clip or something. OoM is  
just plain confusing. GDIError would be less confusing, but not  
really much more helpful.

For the Smalltalk case, what I could see doing is watching my own  
stderr and picking off cairo errors. This gets tricky, because cairo  
functions aren't the only functions in a program that might choose to  
write to stderr, so I end up having to filter somehow.

My goal basically is to create/throw an exception when a Cairo error  
occurs, with as much meaningful information packed into it.

I kind of like Bill Spitzak's proposal of just having the error code  
be a pointer to a string. No string (null) means no error. The one  
disadvantage I see to this is that you can't easily "classify" the  
error codes without parsing the string.

--
Travis Griggs
Objologist
"There are a thousand hacking at the branches of evil to one who is  
striking at the root" - Henry David Thoreau


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://cairographics.org/archives/cairo/attachments/20070705/0e3d7066/attachment.htm 


More information about the cairo mailing list