Re: Some comments about GVFS

[Havoc Pennington <hp redhat com>]

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