Re: assert_handler?
frege wrote:
Has there been any talk about increasing support for debugging in the
next C++? In particular, things like extending assert, adding trace()
(or output_debug_string() or whatever).
More in particular, I wish there was an assert_handler similar to
new_handler. ie when using assert(expression) and the expression is
false, assert_handler is called (if one exists), else it goes back to
the default behaviour.
Basically, I find every big project ends up writing its own
FOO_ASSERT() macro and other debuggin macros, but when I write generic
code, I don't know which assert to use - PROJECTA_ASSERT,
PROJECTB_ASSERT, or just assert(). I'd like to use the C++ standard
assert(), but, as expressed by the plethora of ASSERT macros, the
standard assert is somewhat substandard.
And from there, it would also be nice to add some more debugging
support like trace(), breakpoint(), etc. I know that maybe for some
systems trace() may be impossible, or breakpoint() might be
meaningless, but I think those systems could at least fail gracefully
(even if that meant that the calls did nothing on those systems).
P.S. I think assert and assert_handler, similar to new, should be at
the class level, and then at the global level. Possibly also at the
namespace level?
Now maybe, since assert can be seen as just another function, it could
all be handled by making an assert function, and then carefully
handling link order, but we all know assert is best done as a macro,
and most versions of it pass along file and line number, as well as the
expression as a string. It would be nice is assert_handler was passed
that info as well. Of course, file and line number might be
meaningless in standard-ese, but I think a generic (implementation
defined) 'location' string would be sufficient.
Sorry if that sounds a little quick and half-baked, but hopefully the
gist of the idea is there. Any thoughts?
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, we already know that the two versions of the program are
different. So the real issue is whether any of the differences that do
exist is significant enough that it would affect the outcome of any of
the tests performed on the development version if that test were
performed on the release version. The dichotomy between a program's
development and release build is somewhat reminiscent of Heisenberg's
uncertaintly principle. In its software incarnation, the question is to
what degree a a program can test itself without the presence of the
testing code influencing the result.
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. In other words the actual outcome
is the opposite of the one anticipated.
Greg
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]