exposing dbus error names on the glib client side

[Colin Walters]

On Thu, 2005-06-23 at 14:12 -0400, Havoc Pennington wrote:
> On Wed, 2005-06-22 at 20:35 -0400, Colin Walters wrote:
> > 
> > That would mean interning a new quark for each remote error, which is
> > kind of evil, since there's no way to free quarks.
> > 
> 
> True, but I'm not sure it matters in practice.

I just don't like the idea of requiring unbounded permanent memory
allocation on the client.  Longer term it should be possible to move the
GLib bindings to handle OOM (for most of the large-allocation codepath
anyways) with some GLib work, but we can't do that if it's fixed in the
API.  Also:

> Another option might be some kind of dedicated quark-like system but not
> GQuark

Hmm.  That doesn't seem like it'd be a more pleasant API.

I think the main value of the GError system comes into play when the
caller knows about the domains and codes in use (transitively) by the
callee, and has handlers for them.  But there's no way a non-D-BUS
related bit of code which calls into a method which calls a D-BUS client
function can dispatch on the domain or code, because it can't know them
at compile-time.  Right?

> > But I thought of a semi-clever hack; embed both the error name and
> > message inside the GError message string, separated by a null character.
> > We then have special accessors to get them.
> > 
> > This also solves the server side-problem of sending errors; now a server
> > method can just call 
> > dbus_g_error_set (error, "com.example.Foo.Bar", "blah bla") too.
> 
> Seems awfully hacky to me ;-)

Well, somewhat, yeah.  Relative to the alternatives though it seems the
sanest to me.
-------------- 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/20050623/b9a9a980/attachment.pgp