apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@covalent.net>
Subject Re: cvs commit: apr/network_io/unix sendrecv.c
Date Fri, 04 May 2001 01:07:53 GMT
On Thu, 3 May 2001, Roy T. Fielding wrote:

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

Well, you have just said what I believe in a much more concise way then I
ever could.  :-)  I seriously asked the question because I was hoping for
an answer like this, but couldn't voice it.


Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131

View raw message