exposing dbus error names on the glib client side

[Havoc Pennington]

On Sat, 2005-06-25 at 03:49 -0400, Colin Walters wrote:
> 
> Hmm.  What do you mean "all the way through"?  The sample code I pasted
> was random bits of app code, some of which happens to use D-BUS methods,
> other parts of which call regular GLib functions.  It sucks if you have
> to create a special DBusError thing only for invoking the D-BUS methods.
> Particularly if the code doesn't really care what the errors are.
> 
> > Maybe Dave's GError user data patch?
> 
> From an API standpoint, how would that be different/better?  Or are you
> just talking about that being the implementation instead of the null
> character?
> 
> Could you modify the sample code to show what you mean?

So there are two basic things I was worried about here:

 1. magic string format

 2. a GError that isn't (because normal GError methods don't work 
    on it properly, you have to use special methods)

So the user data patch fixes #1, which is slightly cleaner (since e.g.
we wouldn't crash if trying to use the dbus accessor on a non-dbus
gerror) but probably not an earth-shattering issue.

But, I realized #2 is kind of bogus, at least if we make one change to
your patch: swap the name and message so gerror->message is a
human-readable string as in a normal GError. So what we have if you use
the normal GError stuff is:
  code = SOME_DBUS_ERROR
  message = "human readable string"

and there's an extra field available via an extra accessor if you care
about the dbus details. 

Anyway, thinking about this more I think I was wrong, I didn't think
about it enough.

Havoc