Hi, Benjamin Otte wrote: > To bring up some examples: GdkPixbufLoaders, GKeyFile, GBookmarkFile, > GMarkup.
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. > 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? I 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? 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? You're right that if this class of error exists it's pretty rare. It would probably mean a bug or at least design bug in something, though possibly not your own app. > At least > I'm not very impressed by the error reporting of Gtk when X has > problems. (That one's probably mostly Xlib's fault though). Examples? Any recoverable error it should handle for you or report to you, the main unrecoverable error is BadAlloc which causes a g_error just like out of memory on the client side, and then some X errors are programming errors which GTK often tries to predict for you with return_if_fail but sometimes does not catch. Most X errors I would say are programming errors, the big exception is that if you are messing with another process's windows (as a WM does) there are lots of unavoidable but recoverable errors. Patches adding return_if_fail to avoid all the "programming error" Xlib errors would probably be accepted, is my guess. Xlib is definitely guilty of mixing up different kinds of error into one system that isn't appropriate or convenient for any kind of error... > And to say it once again: It's nice that the object carries the object > around with it. That way I don't have to carry the Error around myself > all the time as an extra argument. 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. Havoc _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
