[cairo] error handling questions

[Carl Worth]

On Tue, 03 Jul 2007 20:08:04 -0400, Behdad Esfahbod wrote:
> > Abusing NO_MEMORY was bad, inexcusable, and must be fixed. But adding
> > UNKNOWN_ERROR is not any better, (and worse in that it actually
> > _looks_ like it's intended as a random catch-all).
>
> Your reasoning works by assuming that defining no catch-all status makes
> people handle errors properly.  That has already failed.

No, I wasn't assuming anything like that.

> An unknown-error status on the other hand, can be used pretty much like the
> current NO_MEMORY is (ab)used, but has the following benefits:
>
>   - Is not confusing to users.
>
>   - Lets developers grep for CAIRO_STATUS_UNKNOWN_ERROR and try to fix
> one or two when they have a few minutes.

Uhm... are you trying to argue "it would have been better if we had
used UNKNOWN_ERROR instead of NO_MEMORY originally". I probably
wouldn't disagree there. But that's not an interesting question at
all. The question is how to fix what we've got, (and UNKNOWN_ERROR is
a non-fix).

> The second one is a huge advantage.  Right now we are stuck in a
> situation that someone's got to go over all CAIRO_STATUS_NO_MEMORY
> instances in cairo and check them...

Yes, that's where we're at right now. And as any are found to not
actually be related to NO_MEMORY they should simply be replaced with
the correct value. Now, if the correct value must be vague because
there's some underlying system that doesn't give us a lot of
information, then the best we can do might be CAIRO_STATUS_GDI_ERROR
or so, and that would be fine, (but CAIRO_STATUS_UNKNOWN_ERROR would
not be).

The point is, right now you might have a program that fails and prints
a totally bogus error message:

	cairo is unhappy: out of memory

And that leads to misleading bug reports. Which of the following
replacements would lead to better bug reports?

	cairo is unhappy: unknown error

	cairo is unhappy: GDI error

I know which one I would prefer to see.

> Just because there is an UNKNOWN_ERROR status define doesn't mean all
> errors should return it.

I don't want anybody to e tempted into using it for any new
code. That's my point.

> 360 lines.  Not portable, probably not even to all versions of libbfd.

OK, so not a _ton_ of code. And some portability concern that we
should be able to test for, (let's land it quick so people can start
letting us know where it fails). But it's darn useful, so I'd like to
have it.

> But main reason that I don't like it is that it's something that glibc
> should have got right in the first place.  Doesn't make any sense for
> apps/libs to have to provide their own :(.

Sure, so let's be responsible and send the patch upstream. But as soon
as we've done that, I'd be fine putting the code into cairo.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://cairographics.org/archives/cairo/attachments/20070704/ee0bbb86/attachment.pgp