[cairo] Making it easier to track down errors

[Mathieu Lacage]

On Fri, 2005-06-17 at 14:41 -0400, Owen Taylor wrote:
> I should say that I think in general:
> 
>         void
>         cairo_set_error_notify (cairo_t                  *cr,
>                                 cairo_error_notify_func_t error_notify,
>                                 void                     *closure);
> 
> has a whole bunch of problems:
> 
>  - It's not handy for debugging: you have to add it to each cairo_t, 
>    the messages you get have no context, and you have to write
>    your own "print an error function"
> 
>  - It doesn't handle errors on cairo_pattern_t ... while you can
>    argue that cairo_pattern_t errors eventually propagate to 
>    a cairo_t, you've lost the useful debug information at that time.
> 
>  - It's language-bindable, since there is no destroy notifier for
>    the closure.
> 
>  - Only one person can set the error notifier on a cairo_t

As a debugging mechanism, this should not be a problem.

> 
> I'd really like to understand what the use cases is for this function...
> why it's being added. It doesn't seem to really address the question
> of making it easy to track down programming errors.

Are you saying you don't like the idea of something like this:

void
cairo_set_error_notify (cairo_error_notify_func_t error_notify,
                        void                     *closure);

Or you just don't see the use of setting it on a per-cairo-t basis ?

As far as I am concerned, I don't really see the use of a per-cairo-t
error notification callback (but it does not bother me either) and I
think a process-wide notification callback for debugging should be more
than enough for the few rare times you need it. 

Of course, I don't have any strong feeling about any of this: I just
think that only allowing users to catch the call to _cairo_error with a
debugger is a bit annoying for said users sometimes. I did end-up
writing some sort of in-process breakpoint setter with symbol resolution
to work around similar limitations in another library and I did not find
that to be a great use of my time so I am trying to make sure I don't
have to do this again ever.

Now, I am not sure trying to reuse a debugging mechanism to add
exception support to the language bindings is such a great idea...
Proper exception support will require much more thought than just
throwing in an exception handler.

regards,
Mathieu
--