using dbus in the platform

[Simon McVittie]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 09 Oct 2007 at 12:51:16 -0400, Havoc Pennington wrote:
>> I'd tend to go for NAMESPACE_try_VERB, which is quite concise, reminds
>> the reader of try/catch or try/except blocks in most languages with
>> exceptions, and has the right implication of "try to do this, but if you 
>> can't,
>> let me know rather than panicking".
>
> We may want to do register_object_path() differently from something like 
> message_set_path().

I think it's reasonable for message_set_path() to be one of your "can't
fail except by OOM" functions, if an object path validator that takes a
DBusError is provided.

> Here is the bright-line difference between "checks" (the current 
> return_if_fail() stuff) and DBusError: it makes sense to handle errors, and 
> it does not make sense to handle failed checks.
>
> That is, the following code is not reasonable:
>
>  try {
>     frobate("foo");
>  } catch (FooIsAnInvalidArgumentToFrobateException) {
>     // ... um, what are you going to do here?
>  }

Yes, in that degenerate case it's clearly silly; but if "foo" isn't a
literal, but is an argument you got from the caller of the function
you're implementing, then it becomes reasonable to want to handle it.

In some cases you'd be able to tell "easily" that the argument is valid
(for instance, "!= NULL") and it's reasonable to make it an
assertion/check.

In other cases, it's difficult or impossible to tell what's OK and what
isn't unless you have access to appropriate libdbus internals. For
instance, try_register_object_path.

I'm not suggesting introducing "try" versions of *every* API function,
but just the ones where it actually helps.

> I do not want to see this - this is why I suggested the separate header for 
> the "checked" variants of functions.
>
> It is *important information* whether a function can fail or not. The 
> functions in libdbus that don't have a DBusError either can't fail (as long 
> as the API contract is met), or they can fail in only one way and indicate 
> that via return value alone (generally they can fail due to out of memory 
> only).

I'm not suggesting adding a DBusError argument to functions that can't
fail - that would indeed be silly - and OOM is a special enough case
that functions that really can't fail except by OOM can have a boolean result
without any extra error reporting.

Neither am I suggesting any sort of blanket change to libdbus -
introducing a _try_ version on a case-by-case basis, wherever the checks
and the API contract are subtle enough that they're easy to get wrong
or only libdbus can know whether you're complying with the API contract,
makes much more sense.

However, at the moment there are cases (like register_object_path) where
it's very hard to tell whether you are actually complying with the API
contract. dbus-python internally keeps track of what object paths are in
use, just so it can comply with the libdbus API. This leads to a large
amount of unnecessarily subtle code that I should never have had to
write - the only reason it works at all is that dbus-python uses a
private bus connection (a shared bus connection would completely break
this approach), and I leak a small amount of memory if OOM
happens at precisely the wrong point, because that's the least bad thing
I can do.

	Simon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net

iD8DBQFHC7rgWSc8zVUw7HYRAiIqAKDWQFXt3qYLpjU7d7EQGUdRSo+dgQCfd2J/
f/9G+Pg0NmF9IKbDFCbr5JE=
=19fX
-----END PGP SIGNATURE-----