[cairo] Making it easier to track down errors
otaylor at redhat.com
Fri Jun 17 11:41:20 PDT 2005
On Fri, 2005-06-17 at 14:30 -0400, Owen Taylor wrote:
> On Fri, 2005-06-17 at 11:24 -0700, Carl Worth wrote:
> > On Thu, 16 Jun 2005 22:55:54 +0200 (CEST), Olivier Andrieu wrote:
> > > 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).
> > I think we could quite easily guarantee that the most cairo would ever
> > want to do after _cairo_error is to return (and perhaps return a
> > value) from a cairo entry point.
> > In fact, the implementation is extremely close to that already. And
> > the attached patch shuffles the few calls to free needed in order to
> > completely satisfy that constraint. I've gone ahead and committed it
> > now, (the close examination of every _cairo_error call turned up a
> > couple of bugs that I had reintroduced which are also fixed in this
> > patch).
> This absolutely doesn't work ... Cairo can guarantee it's own behavior,
> it can't guarantee the behavior of other libraries that might use
> Cairo internally; and it's very plausible that a cairo_t might be
> shared between direct usage from the language binding and usage
> from a library that uses cairo internally.
I should say that I think in general:
cairo_set_error_notify (cairo_t *cr,
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
- Only one person can set the error notifier on a cairo_t
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050617/cd1f315c/attachment.pgp
More information about the cairo