asynchronous error reporting

Robert McQueen robert.mcqueen at
Thu Oct 27 04:16:36 PDT 2005

The glib bindings have the effect that in the service, the method is
invoked synchronously, whether or not the client has made an
asynchronous or a synchronous invocation. This means that when doing
something that is time-consuming, such as interacting with the network,
the service process is blocked within that particular function.
Accordingly we've made most methods just return nothing, and using
signals to indicate whether or not changes have taken place.

Errors can still be returned from functions if a particular request is
invalid or is known not to work, but if the server comes back later and
says "this request failed", what's the best way to signal this error
back to the client?

Things I thought of were just sending an error message out of the blue,
but that would be like a 2nd return from the method call and hence has
no intuitive interpretation in most bindings (where would the exception
go? is this even valid to do?).

Alternatively we could make our own signal to emit when we get an error,
and basically follow the format of error messages inside this signal,
with an error name and such like, but this exposes more implementation
detail about D-Bus to the client that most bindings aim to hide from them.

Anyone got any bright ideas?


More information about the dbus mailing list