first cut of hal service description file

Tako Schotanus tako at
Thu Mar 31 14:23:51 PST 2005

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
> - 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
> - 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"
Regardless of the fact if the exception is explicitly defined or not it 
is important to be able to figure out which exception has been thrown so 
that the caller can decide to handle it or to throw it up the chain. In 
what way will that be made possible? Because just one generic 
DBusException seems pretty useless. Or it will force you to write 
old-style code where return-values tell you if the method-call did its 
job or not (eg. did DeleteFile actually delete the file) and the 
exception will only tell you that something worse happened (eg. the bus 
went off-line, connection failure).


More information about the dbus mailing list