first cut of hal service description file

David Zeuthen david at
Thu Mar 31 14:55:47 PST 2005

On Thu, 2005-03-31 at 17:08 -0500, Havoc Pennington wrote:
> On Thu, 2005-03-31 at 16:42 -0500, David Zeuthen wrote:
> > So, I think what I'm getting at, is that it's indeed useful to include
> > what exceptions apart from DBusException a method may throw in the XML
> > (whether it's hand-written or generated from introspection data). Does
> > that make sense?
> I think I agree it would be useful, _if_ it were reliably there. But I
> think:
>  - for generated-from-object-reflection introspection XML, which I 
>    do think should be the normal case with good programming languages,
>    the info won't be there by default

Well, that depends on how much we allow the developers of D-BUS services
to screw up, cf. my note about annotating the source @javadoc style and
using that for the introspection bits. It is indeed possible to get this
right. But I hear what you're saying, it requires more work from
developers writing D-BUS service. 

Fortunately it's asymmetric: there will be many many more consumers of
D-BUS services than providers of D-BUS services, just like there are
many more web browsers than web servers. So, in that respect, I don't
really think it's crack to require the developers of D-BUS services to
do a bit of extra work. If you factor in that D-BUS services will need
to provide stable ABI's in order to be useful, this is something that
will get fixed eventually.

>  - for hand-written XML, it doesn't seem to me that people will keep 
>    it in sync with the reality of which errors are thrown (especially
>    when errors can be generated by the bus)
> Having it as optional annotation is fine I guess, but I wouldn't want to
> see it considered part of the ABI of the described interface. Which
> would mean e.g. Java should generate "void foo() throws DBusException()"
> not "void foo() throws Bar, Baz"

>From a practical point of view I think developers don't really care
about handling exceptions from the bus; they'll just abort() because
these are very exceptional conditions that apps really shouldn't care
about. Do you disagree?

What I do think developers care about, or rather should care about, is
handling application-specific exceptions such DeviceAlreadyLocked,
CannotAcquireScreensaverMutex, NotificationAlreadyShowing and so forth.

But I don't see how we can effectively enforce that in e.g. Java or
other modern languages if the exceptions to be thrown isn't part of the
ABI of the interface.


More information about the dbus mailing list