Class notes for 2006/02/07
Assert and friends
As we have already seen last week, the Assert macro is a powerful friend in finding bugs. We will today discuss a few techniques that make it simpler to fix a program if it runs into an assertion. To this end, I will show you how to run a program inside a debugger and to inspect a backtrace. In addition, if you run the debugger inside emacs, you even get to see the source code automatically.
For documentation on the gdb debugger, see http://www.gnu.org/software/gdb/documentation/.
Debug and optimized mode
Error checking in Assert macros costs time. In realistic applications, this may be about 75% of the total run time of a program. Since the assertions should tell you where you have bugs in your code, you can go fix them and at one point be reasonably sure that your code at least doesn't trigger any assertions any more (this essentially means that in almost all places your program passes reasonable input parameters to library functions, but it does of course not mean that your program does what you intend it to do). Once your program has reached that state, there is no need any more to check parameters etc. In that case, you should switch assertions off. We call this the "optimized mode".
Runtime exceptions and AssertThrow
Runtime exceptions are a different kind of exception than static assertions that we check with AssertThrow. These exceptions also have to be caught, see http://www.dealii.org/developer/tutorial/chapter-2.step-by-step/step-6.html#plain-The_?main?_function.
We discuss hanging nodes by looking at