[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