Chapter 5Errors.ppt

Pre- and post-conditions Always think about them If nothing else write them as comments Check them “where reasonable” Check a lot when you are looking for a bug This can be tricky How could the post-condition for area() fail after the pre-condition succeeded (held)? * Stroustrup/Programming/2015 Testing How do we test a program? Be systematic “pecking at the keyboard” is okay for very small programs and for very initial tests, but is insufficient for real systems Think of testing and correctness from the very start When possible, test parts of a program in isolation E.g., when you write a complicated function write a little program that simply calls it with a lot of arguments to see how it behaves in isolation before putting it into the real program (this is typically called “unit testing”) We’ll return to this question in Chapter 26 * Stroustrup/Programming/2015 The next lecture In the next two lectures, we’ll discuss the design and implementation of a complete small program – a simple “desk calculator.” * Stroustrup/Programming/2015 * Chapter 5Errors Bjarne Stroustrup /Programming Abstract When we program, we have to deal with errors. Our most basic aim is correctness, but we must deal with incomplete problem specifications, incomplete programs, and our own errors. Here, we’ll concentrate on a key area: how to deal with unexpected function arguments. We’ll also discuss techniques for finding errors in programs: debugging and testing. * Stroustrup/Programming/2015 Overview Kinds of errors Argument checking Error reporting Error detection Exceptions Debugging Testing * Stroustrup/Programming/2015 Errors “ … I realized that from now on a large part of my life would be spent finding and correcting my own mistakes.” Maurice Wilkes, 1949 When we write programs, errors are natural and unavoidable; the question is, how do we deal with them? Organize software to minimize errors. Eliminate most of the errors we made anyway. Debugging Testing Make sure the remaining errors