first cut of hal service description file
David Zeuthen
david at fubar.dk
Fri Apr 1 08:46:14 PST 2005
On Fri, 2005-04-01 at 11:25 -0500, Havoc Pennington wrote:
> On Thu, 2005-03-31 at 23:42 -0500, David Zeuthen wrote:
> >
> > So, you don't you consider it ABI breakage if the application HAL
> > removes / adds exceptions in a supposedly stable ABI? I surely do.
>
> I think it's defined by the interface whether this is in the ABI
> contract.
Exactly. That's why I want to be able to do
<method name="Lock">
<annotation name="org.freedesktop.DBus.GLib.CSymbol" value="hal_device_lock"/>
<arg type="s" name="reason" direction="in" />
<arg type="b" direction="out" />
<throws name="org.freedesktop.Hal.NoSuchDevice" />
<throws name="org.freedesktop.Hal.PermissionDenied" />
<throws name="org.freedesktop.Hal.AlreadyLocked" />
</method>
Now, assume that I can't do that; how in the world am I supposed to
generate Java/C++/Mono/Whatever client code from introspection data such
that it's possible to generate code so I write something like this
try {
d.Lock ("somereason");
} catch (AlreadyLocked e) {
// Tell the user that some other app is using the device
} catch (DBusException e) {
// Handle all other errors here
}
You can't do this, since the introspection data doesn't tell you what
exceptions that Lock() can throw. I have to do this
try {
d.Lock ("somereason");
} catch (DBusException e) {
if (e.name == "org.freedesktop.Hal.AlreadyLocked") {
// Tell the user that some other app is using the device
} else {
// Handle all other errors here
}
}
which just plainly sucks.
And no, this doesn't exclusively apply to Java only; the only thing
about Java is that this language can enforce that you actually handle
the exception.
> The whole point here is, we should not put this in the ABI
> contract for dbus interfaces.
This is mostly the same as saying applications shouldn't throw
exceptions which sounds backwards to me.
David
More information about the dbus
mailing list