[PATCH] do not call _dbus_warn_check_failed on checks

[Daniel Stone]

On Mon, Nov 13, 2006 at 01:01:46PM -0500, Havoc Pennington wrote:
> I think fatal checks gives people the right idea about what the checks 
> mean, namely, a bug in their program. Before people seemed to have the 
> idea that libdbus worked like system calls - that passing in junk would 
> get you EINVAL. I got a little sick of people trying to check the 
> behavior of the checks in test suites and otherwise relying on the checks.

Wow, this utterly sucks.  If this is D-Bus upstream's behaviour, then
I'm removing the D-Bus support for input-hotplug in the X server and
doing something else.

If you ignore the use case of, say, a word processor where you've just
thrown away an hour of someone's work because they dared pass in an
invalid bus pointer rather than bother returning NULL, consider the X
server, where throwing SIGABRT will lead to the server coming down very
badly.  The next time you try to switch VT or restart the X server, odds
are you'll end up with a completely wedged system.

I was discussing this over dinner tonight, and someone asked me why I
was mixing up the critical (X server) and non-critical (D-Bus) paths.
My reply was that I decide what's critical and non-critical.  If it's
truly broken, then I'll call FatalError().  If not, I'll just log a
message about it.

I'm somewhat bemused (and rather depressed) that the upstream attitude
is that D-Bus is a core component on exactly the same level as the
kernel (this was one of the justifications for never being able to
restart D-Bus), yet it does things like throw assert()s.  Given the
situation today, your app doesn't even have to link to D-Bus for libdbus
to be killing your app hard with asserts.

Seriously, the behaviour doesn't even vaguely make sense at all.  For
development, sure.  But there's a reason why the kernel, all POSIX APIs,
in fact every API ever, X, HTTP, etc, return you errors when you ask for
something invalid (a file that doesn't exist, an invalid URL, a
malformed message), rather than ungracefully slaughter you.

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/dbus/attachments/20061114/45907fcc/attachment-0001.pgp