[cairo] Making it easier to track down errors

[Mike Shaver]

On 6/16/05, Olivier Andrieu <oliv__a at users.sourceforge.net> wrote:
>  > Carl Worth [Wed, 15 Jun 2005]:
>  > One difference between the implementation here and the suggestion
>  > above is that here _cairo_error is always called on an error so that
>  > the break on _cairo_error trick will always work whether or not an
>  > error_notify handler is in place. It's _cairo_error that actually
>  > calls the error notify handler (which is simply NULL by default).
> 
> Nice. Would it be safe for language bindings to raise exceptions at
> this point ? (That means that the _cairo_error() call would not return
> and the calling function should have done all its cleanup before it
> calls _cairo_error).

If you're referring to C++-style exceptions, I think that it's not
safe for the language bindings to raise  them from the error hook. 
While the immediate caller of _cairo_error might well have done all
its cleanup, it's not necessarily the case that the rest of the calls
in the chain leading from binding code will have done theirs.  Since
the cairo library itself is not exception-aware, I think you'll end up
with leaks or crashes.

If you're talking about a language binding in which you signal an
exception in a parallel calling sequence, such as in a
Python/JS/Java/etc. interpreter, I think you could do that, and that
might be easier than checking all the returns from cairo API back into
binding glue.

Mike