[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
  - 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.


More information about the dbus mailing list