[cairo] API Shakeup: Consistent error handling for all objects
Bill Spitzak
spitzak at d2.com
Thu Feb 24 10:56:26 PST 2005
Kent Sandvik wrote:
> On Wed, 23 Feb 2005 16:56:28 -0500, Carl Worth <cworth at cworth.org> wrote:
>
>>I propose making all objects in cairo use an error handling scheme
>>similar to cairo_t. That is, rather than each function returning
>>cairo_status_t, most functions are void and error state is stored in
>>the object itself, (and can be queried). An object in an error state
>>is inert, and functions can be safely called on it with no side
>>effects.
>
> I like this approach. Just two quick questions, in case the code is
> threaded, will it cause problems if two threads have a different view
> of the error state?
I thought it was defined that sharing a cairo_t between two threads was
not allowed, they are not thread-safe. You have to use two different
cairo_t's (though they may both be updating the same device). If this is
right then there is no problem as two threads should not be looking at
the same error state anyway.
> Also, could the application code clear the error
> state, causing problems later?
This is for things like the device connection being lost or the disk
filling up for an output pdf file, right? It is not for erroneous
arguments to the cairo calls. So I kind of doubt it is possible to clear
the error.
There should be a way to get arbitrary text describing the error. This
is not like strerror(errno), instead the device-specific backend should
be able to produce totally arbitrary text describing what went wrong
without any need to allocate an error number. Certainly I have never
done anything with errors other than report them to the user, so I don't
think it is necessary to be fancy about this at all, there do not need
to be classes of error of any numbers, just a message. I18N would be
done by having the backend return the message in the appropriate language.
More information about the cairo
mailing list