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

[Kristian Høgsberg]

Carl Worth wrote:
...

> There are some classes of operations which do not fit well with this
> model. For instance, calling cairo_surface_set_user_data on an inert
> surface, and assuming you'll get a destroy notify at some point in the
> future will not work, (since the inert object cannot save the
> data). Immediately calling the destroy notifier might actually work,
> but doesn't seem a good idea. It will probably be best to just make
> set_user_data be one of the few functions that can fail.

I considered this approach when I implemented and I'm not sure we should 
dismiss it entirely.  You could argue that it's a bit unusual, but I 
couldn't come up with a case where it isn't the behavior you want: if 
you've allocated a new object and fail to attach it to the surface, you 
want to free the object and bail out.  Similarly, for ref-counted object 
you to deref and bail out it if you fail to attach it.  For statically 
allocated data you shouldn't do anything on failure, but then, the 
destroy notifier shouldn't do anything in the normal case anyway.

One case I thought of is if you want to wait for memory and then try to 
reattach it.  But this wont work anyway, since when the surface goes 
inert there's nothing you can do with it except get the error and 
destroy it.

Finally, it is possible to get the non-destructive failure behavior by 
first setting the data with a NULL destroy notifier.  If that fails 
nothing will happen, and you get to keep the user data.  If it succeeds, 
setting the data again with a non-NULL destroy notifier wont fail.  But 
maybe that's an implementation detail we don't want to guarantee?

Anyway, I can accept the argument that it's just too unusual and 
probably will lead to many double-free bugs in little exercised error paths.

cheers,
Kristian