apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@ebuilt.com>
Subject Re: cvs commit: apr/network_io/unix sendrecv.c
Date Fri, 04 May 2001 00:51:37 GMT
> We have asserts throughout the server these days.  Do we want to remove
> them all?

I want to remove them all, but won't do so until I've done all of the
other things I want to do.  The problem with asserts is that causing the
server process to core dump is never a good idea, even when a person is
in debug mode, unless the condition being checked would result in a
fatal error in any case (like a later pointer de-ref or divide-by-zero).
Expected run-time errors should just be logged and handled.
In all other cases it is better to bullet-proof the code or simply ignore
that condition as a possibility.  Cosmic rays and memory errors do occur,
so an assert should not be used unless it is a truly fatal condition.

The problem with conditionally-compiled debug switches is they change
the code such that the stuff we test isn't the same as gets deployed,
which can mask race conditions.

However, the main reason that I don't like asserts is that they lead to
programmer mistakes -- people assuming that a condition will never occur
in all environments simply because none of their own debug tests in their
own environment triggered the assert.  I think the code should either be
logically complete (handle all cases) or fail-soft.


View raw message