On Thu, 03 May 2007 15:41:43 -0400, Havoc Pennington wrote: > I'd be for that in the case that the API has a "required ending call," > the equivalent of close(). Then you can "force" error checking on that > last call with a GError or warn_if_unused approach and in theory people > could skip the intermediate error checks. That makes sense. Yes, forcing the user to check the return value when finished with the object is definitely a good idea. Aside for the public error-handling strategy, we've been adopting the same shutdown-on-error approach internally within cairo bit-by-bit. And as we do that, we really need to propagate errors from one object to another. And we've found that forcing a check when disposing of an object is a good way to help us not forget that. We've wondered whether we can change cairo_destroy from void to cair > > I'm not sure there are "unavoidable-and-ignorable" errors. > > To me anything that could happen to cairo_t is probably in this > category... what am I going to do if I draw a rectangle and it fails? Well, for "draw a rectangle", cairo basically says that that can never fail, (if you look at the X interfaces we get, there's no other option). So I think that's an error case that really doesn't exist, as opposed to something that's unavoidable and ignorable. Just look at cairo_status_t---there's nothing like "the requested drawing operation didn't happen" there. > really have no idea what kind of "recovery" code I'd write for that. > Certainly nobody is writing such code that I've seen. I don't even know > where the error check would go - in every widget's expose handler? In > the toplevel event loop? As you said before, at the very least at the "required ending call", (which is cairo_destroy in this case), you should definitely be checking this error. > Is there anything that could happen to cairo_t in this category? I don't > know. I'm mostly assuming there is because I have no idea what the > cairo_t error state is for otherwise ;-) (other than as an internal > "make everything a noop" flag) > > My guess is that out of memory (on client side or X server side) is in > this category in cairo, it silently doesn't draw if OOM occurs, no? There's certainly not a large class of errors that can happen while drawing, (yes, out of memory is one). But the other way you can get an error lodged into a cairo_t is via propagation from some other object. So, if you forget to check a cairo_surface_t's status, (say it's FILE_NOT_FOUND), and then you do "cairo_create(surface)" then the FILE_NOT_FOUND status will propagate into the cairo_t. It would have been kind of nice if GTK+ were creating the cairo_t for the expose handler and then also checking the status, and printing that message. But that's not how GTK+ integrates with cairo---oh, well. And, no, getting a FILE_NOT_FOUND status on a cairo_t is not going to give you a meaningful error message. And no, I wouldn't think it would be sane for anyone to right code to "handle" a FILE_NOT_FOUND status from a cairo_t. But it might actually give enough of a hint to help you know where to look, (or else just go and get a _cairo_error-induced stack trace). And, yes, when you find the cairo_image_surface_create_from_png call that's failing, (and was missing any errro checking), you should add code there to print a meaningful error message. > As long as the individual calls failing don't affect control flow, > there's some "close()" call that reminds you to grab the error, and the > errors are interesting/recoverable in the first place, I agree this is nice. That sounds quite reasonable to me. I don't think everyone will agree on which errors are or are not interesting. And I don't think it hurts at all to be able to fetch an uninteresting status value from an object, (see my example above of cairo_t reporting a FILE_NOT_FOUND status). -Carl
Attachment:
pgpyVU9z4wPMZ.pgp
Description: PGP signature