Re: assert() vs. return(error)

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

The problem is that assertions are often misused as conditional aborts.
But that's a straw man if a project with reasonable discipline decides
to use them properly (or not at all) and Subversion seems to have a lot
of discipline. ;-)

(Note that the fact that assertions should not have side-effects is only
checked if the program behaves the same with assertions enabled and
disabled. If the program is never run without assertions side-effects
can creep into the asserted conditions without ever being noticed. This
then is more confusing to the reader of the code.)

On Tue, Feb 14, 2006 at 07:57:07PM +0100, Peter N. Lundblad wrote:
> On Tue, 14 Feb 2006, Garrett Rooney wrote:
...
> I think the most famous example of this is our path manipulation functions
> that expect canonical paths (no double slashes except where required, no
> slash at the end). It would be both inefficent and cumbersome to have each
> such function check that the input is valid in this case. Here, the input
> validation must be done on a higher level.

So, this might be a perfect example of a relatively unefficient, but
potentially worthy assertion in the above (ie original) sense.

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