Re: Some comments about GVFS
- From: Havoc Pennington <hp redhat com>
- To: Benjamin Otte <otte gnome org>
- Cc: gtk-devel-list gnome org
- Subject: Re: Some comments about GVFS
- Date: Thu, 03 May 2007 15:41:43 -0400
Benjamin Otte wrote:
To bring up some examples: GdkPixbufLoaders, GKeyFile, GBookmarkFile,
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.
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.
] [Thread Prev