[cairo] API Shakeup: Consistent error handling for all objects

[Bill Spitzak]

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.