exposing dbus error names on the glib client side

[Colin Walters]

On Fri, 2005-06-24 at 22:31 -0400, Havoc Pennington wrote:
> On Fri, 2005-06-24 at 17:37 -0400, Colin Walters wrote:
> > On Fri, 2005-06-24 at 17:20 -0400, Havoc Pennington wrote:
> > > Another option maybe is to just expose DBusError - since we're adding
> > > all dbus-specific methods on GError anyhow...
> > 
> > Well, that means that methods which take their own GError will have to
> > do the transformation from DBusError to GError for the case where they
> > simply want to propagate errors up, which is kind of tedious.  For
> > example, with your suggestion, code would look like:
> 
> What I intended to suggest was to use a DBusError all the way through,
> just drop GError entirely.

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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/dbus/attachments/20050625/740a3713/attachment.pgp