[cairo] Idle thoughts on error propagation

[Chris Wilson]

On Thu, 2008-05-01 at 18:14 -0400, Behdad Esfahbod wrote:
> On Thu, 2008-05-01 at 15:13 -0700, Carl Worth wrote:
> > 
> > I can imagine a case where this could be wrong.
> > 
> > The cairo_t context is conceptually transient for what could be a
> > long-standing surface. For example, if I had an application creating a
> > new context for the same surface on every expose event, would it be
> > correct to force the surface to shutdown due to an error on the
> > context?
> 
> My answer to that is "Yes.  A single error means that the surface does
> not contain the drawing that it's expected to have, so it should be in
> an error state."

Just to add an extra refinement: the context error should only be
propagated to the surface when the user tries to draw.

However having reviewed the test suite, I think we can achieve clean
propagation of errors just by using the idiom
cairo_set_source_surface (cr, cairo_get_target (cr2), 0, 0);.
With which the vast majority of the extra checks that I used for
malloc-testing become redundant, and the code itself is arguably cleaner
because we only have to handle the context, rather than both the context
and surface independently.

This doesn't answer the fundamental question of whether we should
propagate the error from the context to the surface. Given that the
rationale for inert objects is that once an irrecoverable error has
occurred during an operation on that object, then we must assume that it
is in an inconsistent state and thus we can no longer use it. We extend
this behaviour to shutdown the object when the user tries to abuse the
API - as after a severe programming error we can no longer trust the
contents of the object match the user's expectations. This is the same
rationale to propagate the error from the context to the surface - the
contents of the surface no longer match the user expectations, so we
should shutdown the object due to its inconsistent state. Consider the
long-lived surface used over multiple expose events, each using a
short-lived context. As the contents of the surface may be blended from
one event into the next, we need to treat the surface as a source from
one event to the next - which through any other use of the API would
propagate the error.
-- 
Chris Wilson