[PATCH] do not call _dbus_warn_check_failed on checks
Havoc Pennington
hp at redhat.com
Tue Nov 14 09:43:46 PST 2006
Daniel Stone wrote:
>> If you want to change the API, argue to change the API. Nothing to do
>> with what happens on failed checks.
>
> Okay:
> Change the API.
>
Good, this is the right discussion.
Here is why the API won't change to return a "you passed in NULL" error
code from every function:
- it will double the size of the API since we have to keep the
existing one and then add variants like
dbus_connection_send_with_error() in addition to
dbus_connection_send()
- nobody will check for these errors (they don't on Windows and other
APIs that do this)
- it means we *can't* warn about the NULL, which means we'll just
silently accept the NULL even though it's very likely a bug.
We can't print warnings about an error that's returned to
the caller because if we return an error the caller is responsible
for it.
- it makes the already low-level API even harder to use by adding
more args to every function (or eliminating other uses for
the return value, e.g. we have to have
HRESULT dbus_message_new(DBusMessage **message_p) instead of
DBusMessage* dbus_message_new(void) )
- it makes it unclear which functions can really fail for reasons
that should be checked, and which only fail due to a programming
error - when using the Windows API, you always have to read
the docs on this to decide if there are any HRESULT that can
sensibly be handled at all (not that MS documents it properly).
With dbus, if there is a DBusError you can be confident that
you should be checking it and not ignoring it.
- it's already possible to write a high-level binding that
verifies all the preconditions in advance (e.g. checks
for NULL) if someone really wants that; in fact for
just the NULL checks you can write this "binding" as
only a header file full of macros. This will avoid any
possibility that libdbus ever warns or exits.
- whatever you may think, it is a common and widely-accepted practice
to have functions without a way to report errors when those
functions have no error cases that can happen in a correct program.
- if we want to make "bug in my code" behavior configurable, it's
better to have a global way to set the "bug/log handler function"
than to screw up the whole API with error returns. Or just
make it configurable, say via an environment variable that changes
the behavior when a bug is detected. Kind of like the one we have.
If you want to write all your code like:
result = foo();
if (result == BUG_IN_MY_CODE)
/* something */ ;
result = bar();
if (result == BUG_IN_MY_CODE)
/* something */;
result = baz();
if (result == BUG_IN_MY_CODE)
/* something */;
Have fun, but don't expect anyone else to want to do that!
If you want to write a new libdbus or a libdbus binding that gives
people the ability to write code like that, please don't let me stop
you, but I wouldn't expect it to be wildly popular.
Havoc
More information about the dbus
mailing list