should request_name org.freedesktop.DBus fail?

[Havoc Pennington]

On Mon, 2005-11-07 at 12:06 +0000, Robert McQueen wrote:
> At risk of talking to myself... on a related note, if you request a
> garbage name, the method returns 0 but does not set an error, because
> the library uses:
>   _dbus_return_val_if_fail (_dbus_check_is_valid_bus_name (name), 0);
> At the start of the function, amongst others.
> 
> This and others like it should either be made to return an error, or the
> fact this function can return 0 in unspecific error cases (rather one of
> the return values in the documentation) made clear in the API
> documentation and spec.
> 

Not a bug. As soon as a _dbus_return_if_fail() trips, that means your
program is broken - we behave exactly as if you passed in unallocated
memory or other garbage. All behavior is undefined as soon as
_dbus_return_if_fail() happens.

Remember you can compile without the _dbus_return_if_fail() in there at
all... and any nonbroken program will work exactly the same without
them.

The docs in this case should say something like "if you pass in an
invalid name, behavior is undefined and your program may crash"

There are two kinds of error:

- programming bugs - resulting in assertion failures
- runtime errors - you should write code to handle these

The difference is in how you handle the error. Let's put it in Java for
example, say you call:

  if (str.length() == 0)

and you get NullPointerException.

The right fix is perhaps:

if (str != null && str.length() == 0)

Or perhaps the bug is elsewhere and str should not be null in this spot.

But this is never the correct fix:

try {
   if (str.length() == 0)
     ;
} catch (NullPointerException e) {
    // what are you going to do here? doesn't even make any sense
}

Now, think about IOException. That is a different case, where it *makes
sense* to have handler code that does something about it. That's why
it's a checked exception that you would normally handle.

(If you're used to Java, note that many APIs fuck this up and throw
checked exceptions for things that are programming errors, thus causing
people to hate checked exceptions. But that's an API bug.)

Anyhow, _dbus_return_if_fail()/g_return_if_fail() are like
NullPointerException. DBusError is like IOException.

There's another/longer discussion of this in the GError documentation,
the dbus model is analogous to GError.

Havoc