[PATCH] do not call _dbus_warn_check_failed on checks

[Daniel Stone]

On Tue, Nov 14, 2006 at 01:42:43PM -0500, Havoc Pennington wrote:
> Daniel Stone wrote:
> >> - 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.
> >
> >These functions do not call abort.
> 
> They configurably do (or just segfault, in many libs). The only 
> difference with libdbus is the default. And recent GNOME even matches 
> dbus on that by setting G_DEBUG=fatal_criticals.

Maybe this is a G* thing, but it's not something I've encountered.

> >> - 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.
> >
> >Environment variables are a horrific API.  If you want to be truly
> >useful, give me dbus_never_abort_my_program().
> 
> I have no objection to adding dbus_set_bug_handler() that gives your 
> handler the string to be logged and returns a value for whether to do
> { default action from env, force abort, force warn, force silent }
> 
> Please, anyone is welcome to write that patch.
> 
> You can even use it to set a global or thread-local error flag which you 
> can then check in your code.
> 
> Much saner than a libdbus-2 or passing needless DBusError* to everything.

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.

> >I still don't see why you see error returns as 'screw[ing] up the whole
> >API'.  It would at least give us a consistent API, rather than the
> >current random hodgepodge where some functions take a GError, some
> >don't, some may fail randomly even without a GError, others always
> >succeed, ...
> 
> 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?
-------------- 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/fbe8586b/attachment.pgp