first cut of hal service description file

[David Zeuthen]

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