[PATCH] do not call _dbus_warn_check_failed on checks

Havoc Pennington hp at redhat.com
Tue Nov 14 12:55:52 PST 2006

Daniel Stone wrote:
> No, it's actually not saner at all, because it means you need to keep
> insane amounts of context around to work out where you were.
> Out-of-band error handling for synchronous calls does not make sense.

Remember we're talking bug handling not error handling, and thus very 
commonly you want to handle all bugs in one global way in all contexts 
(as libdbus does by default, and in the same way that SEGV or other such 
signals can only be handled globally).

If you need context-specific handling, do the following:

extern bool bug_in_my_app;

my_bug_handler(const char *message)
   bug_in_my_app = TRUE;
   return DBUS_BUG_IGNORE;



dbus_connection_send(connection, message);
if (bug_in_my_app)
    /* do whatever you want */ ;

In a multithreaded app, you have to get a little more complex and use a 
thread-local flag instead of a global flag.

Or you could do something like:

extern int ignore_bugs_trap;
void my_push_ignore_bugs(void)
void my_pop_ignore_bugs(void)
   if (ignore_bugs_trap <= 0) {
     fprintf(stderr, "bug in ignoring bugs!");

my_bug_handler(const char *message)
   if (ignore_bugs_trap > 0) {
     return DBUS_BUG_IGNORE;
   } else {

dbus_connection_send(connection, message);

Though, why you would do that I'm not sure, when people do this with 
Xlib it's because certain errors are expected/unavoidable - in all cases 
that metacity does an Xlib error trap for example, libdbus would return 
a DBusError in the equivalent situation.

>> It is not random at all. There is an error if an error can occur, if 
>> only OOM can occur there is some way to detect that (either NULL or a 
>> boolean), and if neither error nor OOM can occur there is no indication 
>> of either.
> How do I know, looking at a function, if an error can occur, witout
> reading the documentation?

You have to read enough docs to know the conventions, but once you know 
them many functions are very clear.

- If there's no return value or out params, you know no error can occur 
(not even out-of-memory).

- If there's a DBusError you know potentially recoverable errors that 
you should probably handle can occur.

- If there is either a return value or out params, you probably need to 
read the docs on those, but there are definitely conventions and 
patterns in libdbus function signatures to help you figure it out.
Virtually always the only error that can occur if there's no DBusError 
is out-of-memory, and that is virtually always indicated by either a 
FALSE return or a NULL return. A _new() function for example will always 
return NULL on OOM.

Of course, there are detailed docs that almost always mention what all 
the params and return values mean, and we're happy to fill in any gaps.


More information about the dbus mailing list