httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@algroup.co.uk>
Subject Re: assert evilness
Date Sat, 09 May 1998 22:02:10 GMT
Paul Sutton wrote:
> 
> On 9 May 1998 ben@hyperreal.org wrote:
> > ben         98/05/09 08:00:50
> >        n = GetFullPathName(szFile, sizeof buf, buf, &szFilePart);
> >   -    assert(n);
> >   -    assert(n < sizeof buf);
> >   +    ap_assert(n);
> >   +    ap_assert(n < sizeof buf);
> 
> Am I the only person that thinks asserts() are basically evil?

I certainly hope so.

> If there is a risk of an error occurring, we should trap it, log it, and
> do something logical, like move onto the next request or exit. Taking this
> code as an example, if an assert here gets triggered, we log an almost
> meaningless (to the end user) error ("assertion failed: n") or similar.
> The process then exits, killing all the other threads which may be
> processing requests. Modules don't get to clean themselves up, no cleanups
> are run. This client gets a no-data response. All other clients in
> progress get dropped whereever they are.
> 
> Of course, if assert itself is used (rather than ap_assert), things get
> even worse, since you lose the error tracking on release builds, thus
> potentially introducing errors (and buffer overruns) into the most
> important place where they should not exist: production code.
> 
> In fact I'd go as far as proposing a new rule for the style guide:
> 
>  * assert()/ap_assert() should never be used.

Yeah right. And we should all write bug-free code, too.

I suppose as the main asserter I should do some justification. Yes, in
an ideal world, every error will be handled. There will also be thing we
believe must be true, but are not absolutely confident that the code
will make that guarantee. Asserts are definitely for this case (that is,
I assert things I know will never be false if everyone has written their
code correctly). The end-user experience is irrelevant, because the
end-user should never experience it.

I admit that I also use asserts in a second scenario: where I know it
_could_ happen despite correct code. The rationale here is that it will
only happen when someone is deliberately trying to break things, not in
normal operation. The point is to quickly and easily prevent the
loophole, which means I seal more per programming-hour than if I
elegantly wrap them up with error messages and clean handling of the
next request. If they come up frequently, then by all means we should
wrap them properly.

And on that note, I would observe that I am not aware of any assert in
Apache ever even triggering, let alone causing a user confusion.

Asserts are basically good, and most programmers do not do them enough,
IMNSHO.

Cheers,

Ben.

-- 
Ben Laurie            |Phone: +44 (181) 735 0686|  Apache Group member
Freelance Consultant  |Fax:   +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |
A.L. Digital Ltd,     |Apache-SSL author    http://www.apache-ssl.org/
London, England.      |"Apache: TDG" http://www.ora.com/catalog/apache

Mime
View raw message