exposing dbus error names on the glib client side
hp at redhat.com
Sun Jun 26 08:43:02 PDT 2005
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
> 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.
More information about the dbus