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."
Design-by-contract is tha shiznit. It keeps your code base quite stable.
At my place of employment we use Asserts liberally but with an emphasis on using them properly. Specifically, asserts are not a substitute for appropriate error handling. An assert should be used only as a mechanism for bringing developer or tester attention to a special case or flaw and making it convenient to debug (by providing a change to break in). Subsequent error handling should still follow. Another way to look at this is that asserts should always be ignorable (the product doesn't crash, corrupt data, or enter an unrecoverable state if the assert is ignored).
Moderator hint: a comment is neither "Flamebait" nor "Troll" if it is true.
Tom Yager of InfoWorld had an article that spoke to this issue, a few weeks ago. He was talking about how most OSes fail to guard applications against timeouts and hardware failures. They leave it up to application developers to bloat their code will all kinds of handlers. Most applications simply die when faced with these kinds of problems. It would take far too long to code for all the possibilities, and cost too much.
I checked out a copy of shipping code and asserted it all over, including some asserts that other developers said "now you are just being silly, how can this assert not be true". Within hours we found tons of dormant bugs all over the place and two of the "silly" asserts were triggered.
Our bug count list went down by 50% within a week of asserting the code, and later on, in several occasions when some customers reported bugs all we had to do was run the instrumented, asserted version and the asserts caught the bug at once.
I disagree. To co-opt your analogy, asserts are more like the walk-around you do on your car before you get in to drive away. (Er, you did read the owner's manual for your car, didn't you?)r t(HoodIsLatchedDown);
e.g.
assert(CarStillHasFourWheels);
asse
These are assumptions that the program, once it is debugged, should be able to rely upon. They check that the program in internally consistent. However, it pays during debugging to have the program test those assumptions. It could just be that what you assumed to be true, isn't.
When an assumption proves to be wrong (the assert fires) the program stops and tells you where the fault was found, lets you bring up a debugger, etc.
Checks are a different thing from asserts. Checks should, once the program is released, keep the program from processing corrupt/illegal data, when such data might be expected (like input from an operator). If your program is (truely) internally consistent, then only the inputs (and status of output operations) should need to be checked for the program to run.
You never turn off checks in production code, but at some point you can take off the training wheels (assertions).
And before anyone can jump on me about assuming anything while programming, take a look at your own code. Unless you test every freakin' index and/or pointer every freakin' time you use it, you are making assumptions on almost every line (at least, with C/C++ code).
-- I have monkeys in my pants.
Perhaps, but no library code should ever cause the whole application to abort, ever. There are few absolutes in software development, but this is one of them.
The library code is entitled to screw up whatever internal data it likes, and to give me whatever garbage out if I put garbage in, but it is not allowed to screw the rest of my program (and thus to circumvent any graceful-shutdown error-handling system I have in place there).
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Of course, using assertions heavily can incur a significant performance hit, which may or may not be acceptable in your particular application. [...]
Interestingly, the performance hit seems to be almost negiglible on an AMD Opteron in 64-bit mode with gcc 3.4, as long as the assertions themselves are trivial. AMD must have done some really nice things with the branch prediction unit. Way to go.
And yes, I do agree that assertions belong into production code. I cannot count the number of times when they have saved our butts and exposed design or coding flaws. The "impossible" can and does happen more quickly than people would make you believe in general.
Assert() is a big assest to program maintanence and debugging.
Bad uses of assert() are like bad comments: they do nothing to help you. Good uses of assert() serve two purposes: (1) to document assumptions made by the code, and invariants that must be maintained, and (2) to make debugging easier when and assumption/invariant is violated.
When reading code, you know there are probably some corner cases that don't work correctly. There are going to be assumptions embedded in the code. Future maintainers of the code need to know these assumptions; they can either find it by violating them and then tripping over the resulting bugs, or else by reading comments.
is as readable as a
to the same effect, except that the assert() statments are machine-checkable.Assert() follows the principle of "fail fast": when something goes wrong, you want the program to stop right away, before it starts corrupting things. When you get a backtrace at (or soon after) the problem occurred, it is much easier to track down what's gone wrong, than if the program crashes from a null pointer exception a few million instructions later. Or worse, the corrupt data might not be noticed for a long time; at that point you can all you know is that _some_ piece of code corrupted data. An assert() can significantly narrow the search for the offending line(s).