Slashdot Mirror
Do Programmers Actually Use Assertions?
P.Chalin queries: "Do programmers actually use assertions (like the assert statement of various programming languages)? If so, what should be done when errors or exceptions are raised during the evaluation of an assertion? I am collecting opinions and stats via a short questionnaire. Thanks."
Assertions (usually) are a preversion of the failfast principle, because they can be turned off. For the same reason you can't fit a 120v plug in a 240v outlet, error checking in software should be a permanent and reliable function of the design of the system.
Either your software is broken, or it isn't. If it is, you (and the users) need to know about it as soon as possible to prevent little errors from causing big errors.
Now, if you want to have an assertion that cannot be disabled, and is basically just syntax sugar for if(condition) throw new SomeException();, that could be useful. But exceptions that can be disabled only lead to a false sense of security.
Yes and in fact if you look into GCC there is more checking code than most people think because most of the time in a released compiler these checks are not enabled. (--disable-checking). In fact in some cases even on the main development some checking is not enabled by default because it just take so long (like 5 days) to just bootstrap the compiler. I am taking about gcac checking. Also RTL checking takes a long time too.
l ag ,rtl,tree is fun as it takes 5 days to build a compiler even on a fast computer.
--enable-checking=assert,fold,gc,gcac,misc,rtlf
Sure, better assert() than nothing, but using assert() in this case is semanticaly wrong. The right thing to do is to check for the error condition:
// or whatever
if(malloc() != NULL) {
perror("malloc");
exit(1);
}
Again, assert() is for checking for situations that should never hapen (but can happen by a fault in programming logic, that the assert() is made to catch), not for possible runtime errors.
Assertions do not detect runtime errors, they do not even detect incorrect assumptions about data formating, they detect programming errors. An assertion is a statement you make what the state of some portion of the program at that point, if the library is asserting on you then either the assert (and the library itself) is wrong or your use of the library is wrong, either way the assert has done exactly what it was supposed to do - alerted you to a programming error.
[Set Cain on fire and steal his lute.]
Assertions allow the programmer to do checking for conditions that would indicate a bug in the code, in an attempt to identify the problem sooner, as the sooner you see the problem, the easier it is to find and fix.
Having assertions only exist in debug code is also an important principle, that actually allows them to be more useful. For example, if I have some very low-level routine that is time critical, I am not going to want to do parameter validation in the low level routine, particularly if bad parameters are reflective of a bug in the calling code.
The assert allows me to do robust checking for programmer-errors, while not screwing up the performance of the released product. For example, in an object ref-counting scheme, I have asserts all over the place in the low-level ref-counting mechanisms to ensure that nobody tries to do something like add-ref the object once it's destruction sequence has started, and various other programmer-errors.
I don't want these sort of checks in the release code. Another example -- I want the C-Runtime library in debug mode to validate all the parameters that I pass it as best as it can, but I would be REALLY pissed if it were doing those checks in release mode, since it would effectively slow down code of mine that is known to be bug-free.
As a general rule, asserts should be used to identify conditions that in theory can't exist, or that indicate an error on the part of the caller.
No way. Not me. I'm a poser.
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck