Re: assert() vs. return(error)

On Thu, Feb 16, 2006 at 03:17:02AM +0100, Branko Čibej wrote:
> Christian Stork wrote:
> >Assertions are defined by their use. Normally, that means that they act
> >as run-time aborts in the debugging version when the asserted condition
> >isn't met. The shipped version of the code is compiled without
> >assertions.

> >Implications of this definition:

> >- assertions act as checked documentation
> >- assertions should not have side-effects
> >- assertions don't need to be very efficient

> >It seems that subversion and others would like to have something like
> >checked documentation combined with a conditional abort and use assert()
> >for that. Maybe a different name like require() would be a better
> >choice, since it prevents confusion with the intended usage of C's
> >assert().

> >The folklore argument in favor of assertions over documentation is, IIRC:
> >"Assertions catch the error as early as possible." I might add
> >"...while debugging."

> I really can't agree about the "while debugging" bit. IMNSHO
> "development" and "release" versions should behave identically,
> otherwise you have to do all your QA twice.

Note that in my mail I neither argued for or against assertions in the
above sense. I just said that assertions using C's assert() macro are
meant to "catch the error as early as possible ...while debugging." And
I justify the "...while debugging" bit by looking at their intended
usage. You seem to argue that one should not use assert() but only
require(), which is a different subject.

Now, on this different subject I disagree with you. :-) QA should be
done on the code without assert()s (but with require()s)! Of course,
developers run the test suite with assert()s enabled, too.

The reason why QA is done with disabled assert()s is that assert()s
could be very inefficient and performance is certainly part of the Q
that is being A'ed. Another reason why assert()s shouldn't be in the
final product is that the assert()s proper could be incorrect (this
happened much more often to me than I would have expected) and you don't
want your final product crash because of a false assert.

> Furthermore it's quite likely that a bug reported against the release
> version can't be reproduced in the debug version.

How can this be if assertions don't have side-effects? Are you talking
about timing issues? If so, tough luck. The bug needs to be debugged
without assert()s enabled.

> This debug- vs. release-mode dichotomy comes from the commercial world
> and its paranoia about reverse engineering. Here, we *like* reverse
> engineering.

I have no idea where this comes from. Can you give some more details?
I don't know anything about real-world reverse engineering but I'm not
sure that "effectless" assertion code might not even confuse the reverse
engineer.

-- 
Chris Stork   <>  Support eff.org!  <>   http://www.ics.uci.edu/~cstork/
OpenPGP fingerprint:  B08B 602C C806 C492 D069  021E 41F3 8C8D 50F9 CA2F
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org