first cut of hal service description file

[David Zeuthen]

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.

Cheers,
David