Re: GError update

[Havoc Pennington <hp redhat com>]

Tim Janik <timj@gtk.org> writes: 
> oh havoc. first you make me write a lengthy mail on the user_data
> and allocation stuff, and now you get rid of only part of it without
> giving reasoning.

The issues were: user data, names of alloc/free, and the GError**.
I removed user_data which we all agree on, Owen posted reasoning for
the alloc/free stuff.

So: reasoning on GError**. Basically I don't like the static object,
since you have to call a _free() function on it anyway, and then the
error has no NULL state. Or you'd have to make up a magic one.

So you are proposing:
 
 GError err;
 g_error_init (&err); /* can replace with = G_ERROR_INIT as you said */

 frobate (&err);

 if (err.domain != G_ERROR_NONE) /* This is what I really don't like */
  {
    
    g_error_free (&err);
  }

This has the advantage of being just like CORBA, I suppose.

I like this better though:

 GError *err = NULL;

 frobate (&err);

 if (err != NULL)
  {

    g_error_free (err);        
  }

Basically I think G_ERROR_INIT/g_error_init() and err.domain !=
G_ERROR_NONE are gratuituous stuff to learn and remember, simply
checking pointer != NULL seems simpler to me. Also, using a static
object helps tempt people to leak memory be not calling
g_error_free(), I know CORBA is a huge source of mem leaks like this.

We could make all the functions take GError** as you say, but that is
confusing methods on GError with functions that manipulate a GError
return location. As I said, in GConf they are named properly, but
glib's naming scheme confuses namespaces and object methods.

> what i see here is mostly picking worst behaviour of all the
> different schemes we discussed.

That's not true, the only issue we still disagree on is this GError**
bit, and my and your proposals are almost exactly the same for user
code, see above.

Havoc