glib bindings (Was Re: [patch] gobject sender and pid)

David Zeuthen david at
Mon Mar 13 20:28:28 PST 2006

Hey Havoc,

On Mon, 2006-03-13 at 22:50 -0500, Havoc Pennington wrote:
> As I said before, if the rationale is docs, just put it in the docs. I
> don't see how your argument above is not solved by docs? In fact, only
> _one_ _language_ we currently bind even _supports_ marking exceptions on
> methods in any way other than docs.[1]

There is no good solution on how to document D-BUS methods yet; where's
the support in Doxygen or gtk-doc? This is actually a problem we ought
to solve too :-)

> If this is some kind of fundamental problem with a type system, every
> language except Java has the same problem, and they seem to be
> surviving.
> Anyhow, I just haven't seen anyone address the points I've made on this
> topic. I still think your arguments support javadoc @throws tag, rather
> than the Java throws keyword.

And I still maintain that what exceptions a method throws is part of the
ABI and parts of HAL even rely on this [1]. Thus, it's pretty useful for
tools that does ABI checking; for example some enterprise Linux vendors
actually checks this when providing upgrades to customers. So if someone
wants to update HAL in from RHEL8 to RHEL8U1 and the new HAL now throws
SomeNewException on the method Foo on interface Bar there's an easy way
to catch this. This is preferable to just seeing (badly written)
application XYZ crash or misbehave.

Yes, I'm still aware D-BUS is about remote procedure calls so any
unforeseen exception may be thrown should someone change the transport
to e.g. TCP, tunnel it over X or whatever. To this I only have to say
that most application developers seems to be ignorant of transport
exceptions (just bail / recover if the bus throws an error) but they
should at least be interested in the exceptions thrown by the service
they are using.

There's the programming language angle too. I submit that a programming
language is larger than whatever specification defines it insofar there
is a bunch of useful tools. You know, some day static checking for
$FAVOURITE_LANGUAGE will help developers find bugs, like some user not
checking for some exception. Not including exceptions that a particular
service may throw just makes this harder although not impossible.

[1] : If a method throw the org.freedesktop.Hal.Device.PermissionDenied
exception, there is a well-defined way to handle this, e.g. use possibly
use PolicyKit to get the privs you need. In fact, HAL guarantees that
the first word of the description is the name of the privilege the user
don't have. See for details.

> [1] OK I realize that pedantically you can declare throw in C++ for
> example, but in practice only Java
> >  2. Should we install the introspection XML somewhere? As discussed
> >     in the thread about a year back I don't think there was any
> >     consensus.. Ideally the hal-devel or PolicyKit-devel RPM packages
> >     or whatever would include this just like we include header files
> >     and library stubs in such packages. I don't really think D-BUS
> >     services are much different.
> I don't remember the previous discussions here, surely we have discussed
> it though?

I don't remember, sorry, maybe we should discuss it again.


More information about the dbus mailing list