Re: glib' GError.

[Mathieu Lacage <mathieu eazel com>]

Havoc Pennington <hp redhat com> writes:

> Mathieu Lacage <mathieu eazel com> writes: 
> > 1) stupid API renamings:
> > 
> > g_set_error -> g_error_set
> > g_propagate_error -> g_error_propagate
> > g_clear_error -> g_error_release or g_error_clear
> 
> That's wrong - these are not methods on GError, they're convenience
> functions that happen to be related to GError.
>  
> For the data, we originally decided against, but I think are now
> thinking it would be OK. But in addition to the message; otherwise
> it's too hard to print the message. And there should always be a
> message so people can write generic error display code.
> 
> struct _GError 
> {
>   GQuark       domain;
>   gint         code;
>   gchar       *message;
> + gpointer     data;
> + GDestroyNotify dnotify;
> };

I am nitpicking: 

struct _GError 
{
   GQuark       domain;
   gint         code;
   gchar       *message;
   gpointer     data;
- GDestroyNotify dnotify;
+ GDestroyNotify data_notify;
};


> 
> and:
> 
> GError*  g_error_new_with_data (GQuark         domain,
>                                  gint           code,
>                                  gpointer       data,
>                                  GDestroyNotify dnotify,
>                                  const gchar   *format,
>                                 ...) G_GNUC_PRINTF (3, 4);
> 
> Also g_set_error_with_data(), etc. as appropriate. The standard
> functions shouldn't require data; 99% of the time you don't want data.
> By default data would be NULL of course.
> 
> The problem with the data is that errors become uncopiable. Unless we
> have a CopyFunc in addition to the DestroyNotify. I'm not sure what to
> do about that. I suppose the data field is enough of a
> crufty/rarely-used thing that we could require the copy func. Though
> we are doubling the size of GError here.
> 
> For the CORBA bindings, I would fill error->message with something
> readable for the standard CORBA system exceptions, such as "failed to
> communicate with the component 'HelpBrowser'" or the like, the best
> message you can generate given the available information.

sounds good.

Thanks for the input.

Should I go ahead and make a patch without CopyFunc method ?

Mathieu

> 
> Havoc
> 
> 
> 

-- 
Mathieu Lacage <mathieu eazel com>