Xref: utzoo comp.lang.eiffel:260 comp.lang.c++:3625 Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!murtoa.cs.mu.oz.au!munnari.oz.au!uqcspe!batserver!bigm From: bigm@batserver.cs.uq.oz (Michael Pilling [Real people drink purple milk]) Newsgroups: comp.lang.eiffel,comp.lang.c++ Subject: Re: Eiffel vs. C++ Keywords: Assertions Message-ID: <807@batserver.cs.uq.oz> Date: 11 Jun 89 10:48:34 GMT Sender: news@batserver.cs.uq.oz Reply-To: bigm@batserver.cs.uq.oz Followup-To: comp.lang.eiffel Organization: Computer Science Department, The University of Queensland, Brisbane, Australia Lines: 106 Larry Morris in a recent article writes > > can talk about the very idea of reusable software components without > > assertions... > > maintained by the amplifier). Yet of widely available programming > > languages, only Eiffel has these notions. > Assertion checkers, of course, have been used for years as tools outside > the scope of the language, as libraries, or extracted by tools from > code comments. Placing assertions within classes as part of the language > is, I must agree, a very powerful feature. But Eiffel's design philosophy > calls on programmers to define their classes with assertions in addition > to coding their implementation; something most programmers aren't used to > doing and may view as an onerous task. Since assertion checking isn't any > better than the assertions dreamed up by the programmer, I'm skeptical of > using it to "replace" unit testing. I have been encouraging my group software project students to use assertions, and have found that they take some time to get into the swing of writing effective and prudent assertions. This feeling is based on their reactions, I have yet to mark their code (uggggh). Like anything there is a learning curve and a few people will never really get the hang of it. This is not to say assertions are a bad feature, it mearly reveals those who should should be programming and those whose talents lie in other areas. (Perhaps they could help me with my spelling :-) ) I have been using assertions for 3 years and felt obliged to point out that they are not intended to "replace" unit testing but to simplify and augment it. I have found assertions to have the following benifits in whatever language you choose to implement them. 1. Carefully chosen assertions clarify your understanding of the code you are writing or reading and force you to reason about what you are really doing and it's consequences. I have found this to be the most important benifit. It allows you to produce clearer, simpler and more efficient CORRECT code. 2. Error detection is increased. You can't fix them if you don't find them. In a large library module, certain code may never be executed until it fails. This may be 2 or 5 years down the track. Or the error may not manifest 99% of the time because one errornous result in a record/structure is only occasionally accessed. Assertions add another layer of testing - those of self consistency and plausability e.g.s While traversing a doubly linked list you can assert that the current link points back to where you came from. A positive square root should be smaller than the input and when squared should give the input. 3. Errors are detected close to their occurence in space and time. Symptoms of the error may be much further away when the real causes have been obscured. This makes fixing the bug easier because you don't have to waste so much time looking for it. e.g. Space - Assertions fail in your binary search routine - jumping to the bottom half of the array actually gave you a smaller key!! Conclusion: The caller lied when they claimed the array was sorted. Saved from wasting time trying to debug the correct binary search routine. Time - Stange errors are occurring in your program. You suspect the memory arena's been trashed but have no idea who did it and when. Assertions can often detect the culprit soon after they commit the crime. 4. When you think you've fixed the bug the saftey net is still there to tell you you were wrong. In libraries this to can be useful to detect bugs in infrequently used code rather than letting them slip through unnoticed. 5. They can make programs more robust and protect data by stopping their progress in emergancy situations. Real Life example: Data General AOS/VS operating system utility "Exec" hung itself after uttering: Internal inconsistancy error - negative time encountered. In reality, one of the sysops had corrected the time of day because it was fast. Exec caught itself completing a task before it started and thought the clock hardware had failed. It correctly aborted system processing rather than risk damaging timestamps used for backups and other data consistancy functions. 6. You can avoid buggarising your code with error handlers. Why should you attempt to clean up other peoples mistakes. Your code is simpler and more likely to be correct. eg When I did the group software project I was the only one to use assertions. During intergration, people would run to me saying YOUR module had ANOTHER assertion failure. More often than not, I had the pleasure of replying "Oh, that means your not sorting that array you passed me like you were supposed to." I have personally found the use of assertions to save me 80% of my previous debugging time and effort. They allow you to tackle problems that would be almost insumountable otherwise, particularly when useing malloc & free. Like any good investment they pay many returns over a long period. Assertions should be included in the language (definition and compiler proper) so you can turn them off (at your own risk). Preprocessed assertions often produce much more code per assertion and can not check that your assertions do not have side effects. (Side effects prevent you from turning them off because you program behaves differently.) Michael Pilling, Computer Science Department, University of Queensland, St Lucia, 4067 Australia.