Re: glib' GError.

[Havoc Pennington <hp redhat com>]

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;
};

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.

Havoc