Re: assert_handler?

frege wrote:


The trouble with an "assert_handler" - and indeed with any kind
extension to assertions - is that it is likely to prove
counterproductive. There are, essentialy, two ways for a programmer to
make the best use of assertions. The first is to use them extensively -
the more assumptions that are verified as the program executes the more
thoroughly the program will have been tested. And the second way almost
seems to contradict the first - and that is for a programmer to
minimize the overhead of assertions in the program under development.

The reasoning for the latter goal simply derives from the fact that
assertions do not participate in the program's execution logic. They
are not part of the program being written - and indeed they are usually
completely removed (or disabled) as soon as the program has been deemed
ready for release.

Now it is important for us, as programmers about to release a program,
(note that if you are not a programmer you can pretend to be one in
order to follow along) to have a great deal of confidence that the
program we are about to release, is as close to identical as it
possible to the program that was actually tested. Clearly if we ship a
different program than the one we tested, we will have no idea how well
the shipping program actually works - not mention all the time we
wasted while testing something else.

Now it should also be evident that the more complex and elaborate the
assertion mechanism in the development version, the more that program
will differ from the release version. Furthermore, the larger the
program in question - and the greater the degree of its complexity -
the more likely that such differences will matter: that bugs will
emerge in the release version that were not reproducible in the
development version. For example, timing-related bugs in particular can
often remain latent in the development versions of a program - simply
because those versions tend to run slower than the release version. The
additional overhead is due - not only to assertions - but often due to
unoptimized binaries that are more conducive to source level debugging.

There is another risk that elaborate assertion handling poses to
software development: and that is the greater likelihood that bugs will
creep into the assertion-handling code itself. Bugs of this nature are
extemely expensive in terms of their productivity cost to a project.
Essentially any time spent debugging code that is not part of the
program being shipped - has to be written off as a total loss. Large
scale software development is expensive enough as it is, and costs of
this nature can imperil a budget.

But the strongest argument against an assertion handler, in my view,
remains the one I first stated. By eroding the confidence we can place
in the efficacy of our software testing efforts, we find ourselves in a
worse position when it comes time to release the program than we would
have been without them - even though the entire reason that we had for
adopting assertion handlers in the first place was to improve the
quality of our testing efforts and thereby leave us in a better
position when it came time to ship.