Fall 2007 CS 225 Program Correctness and Efficiency Chapter 2
Fall 2007 CS 225
Program Correctness and Efficiency
Chapter 2
Fall 2007 CS 225
Chapter Topics
• Three categories of program errors
• Exceptions
• Testing strategies
• Assertions and loop invariants
• To analyze an algorithm’s efficiency– big-O notation
Fall 2007 CS 225
Program Defects and “Bugs”
• A program may be efficient, but is worthless if it produces a wrong answer
• Defects often appear in software after it is delivered
• Testing can never demonstrate the complete absence of defects
• In some situations it is very difficult to test a software product completely in the environment in which it is used
• Debugging: the process of removing defects
Fall 2007 CS 225
Types of Errors
• Syntax errors
• Run-time errors
• Logic errors
Fall 2007 CS 225
Syntax Errors
• Syntax errors are mistakes in the grammar of a language
• The Java compiler detects syntax errors during compilation and requires you to correct them before successfully compiling the program
Fall 2007 CS 225
Run-time Errors or Exceptions
• Run-time errors– Occur during program execution– Occur when the JVM detects an operation that it
knows to be incorrect– Cause the JVM to throw an exception
• Examples of run-time errors include– Division by zero– Array index out of bounds– Number format and Input mismatch error– Null pointer exceptions
Fall 2007 CS 225
Logic Errors
• A logic error occurs when the programmer or analyst– Made a mistake in the design of a class or method– Implemented an algorithm incorrectly
• Most logic errors do not cause syntax or run-time errors and are thus difficult to find– Sometimes found through testing– Sometimes found during real-world operation of
the program
Fall 2007 CS 225
The Exception Class Hierarchy
• When an exception is thrown, one of the Java exception classes is instantiated
• Exceptions are defined within a class hierarchy that has the class Throwable as its superclass– Classes Error and Exception are subclasses of
Throwable– RuntimeException is a subclass of Exception
Fall 2007 CS 225
Throwable Class • Throwable is the superclass of all
exceptions
• All exception classes inherit the methods of throwable
Fall 2007 CS 225
Throwable Methods
• String getMessage() returns the detail message
• void printStackTrace() prints the call stack
• String toString() returns the name of the Exception followed by the message
Fall 2007 CS 225
Checked vs Unchecked Exceptions
• Two categories of exceptions– Unchecked exception may result from
• Programmer error• Serious external conditions that are
unrecoverable
– Checked exception • May be beyond the control of the programmer• Must be addressed in the program
Fall 2007 CS 225
Exception Handling
• When an exception is thrown, the normal sequence of execution is interrupted– Program stops– JVM displays an error message
• The programmer may override the default behavior by– Enclosing statements in a try block– Processing the exception in a catch block
Fall 2007 CS 225
Uncaught Exceptions
• When an exception occurs that is not caught, the program stops and the JVM displays an error message and a stack trace
• The stack trace shows the sequence of method calls, starting at the method that threw the exception and ending at main
Fall 2007 CS 225
The try-catch-finally Sequence
• Avoid uncaught exceptions– Write a try-catch sequence to catch an
exception– Handle it rather than relying on the JVM
• Catch block is skipped if all statements within the try block execute without error
Fall 2007 CS 225
Error Recovery
• Exception handling provides the opportunity to– Recover from errors– Report errors
• Users are a common source of errors; user errors should be recoverable
Fall 2007 CS 225
Error Recovery
try { /* code */ }catch ( Exception var) { /* recovery */}
finally { /* */ }• Catch block within the first catch clause
having an appropriate exception class executes, others are skipped
• Compiler displays an error message if it encounters an unreachable catch clause
Fall 2007 CS 225
The finally Block
• When an exception is thrown, the flow of execution is suspended and there is no return to the try block
• There are situations in which allowing a program to continue after an exception could cause problems
• The code in the finally block is executed either after the try block is exited or after a catch clause is exited
• The finally block is optional
Fall 2007 CS 225
Throwing Exceptions
• Instead of catching an exception in a lower-level method, it can be caught and handled by a higher-level method– Declare that the lower-level method may
throw a checked exception by adding a throws clause to the method header
– Can explicitly throw the exception in the lower-level method, using a throw statement
Fall 2007 CS 225
Throwing Exceptions (continued)
• The throws clause is useful if a higher-level module already contains a catch clause for this exception type
• Can use a throw statement in a lower-level method to indicate that an error condition has been detected
• Once the throw statement executes, the lower-level method stops executing immediately
Fall 2007 CS 225
Catching Exceptions Example
Fall 2007 CS 225
Guidelines• You can always avoid handling exceptions by
declaring that they are thrown, or throwing them and letting them be handled farther back in the call chain
• It is usually best to handle the exception instead of passing it along
• The following are recommended guidelines:• If an exception is recoverable in the current method, handle the
exception in the current method• If a checked exception is likely to be caught in a higher-level
method, declare that it can occur using a throws clause• It is not necessary to use a throws clause with unchecked
exceptions
Fall 2007 CS 225
Testing Programs
• There is no guarantee that a program that is syntax and run-time error free will also be void of logic errors
• The “best” situation is a logic error that occurs in a part of the program that always executes; otherwise, it may be difficult to find the error
• The worst kind of logic error is one that occurs in an obscure part of the code (infrequently executed)
Fall 2007 CS 225
Sources of Logic Errors
• Most logic errors arise during the design phase and are the result of an incorrect algorithm
• Logic errors may also result from typographical errors that do not cause syntax or run-time errors
Fall 2007 CS 225
Structured Walkthroughs
• One form of testing is hand-tracing the algorithm before implementing
• Structured walkthrough: designer must explain the algorithm to other team members and simulate its execution with other team members looking on
Fall 2007 CS 225
Testing
• Testing: exercising a program under controlled conditions and verifying the results
• Purpose is to detect program defects after all syntax errors have been removed and the program compiles
• No amount of testing can guarantee the absence of defects in sufficiently complex programs
Fall 2007 CS 225
Types of Testing
• Unit testing: checking the smallest testable piece of the software (a method or class)
• Integration testing: testing the interactions among units
• System testing: testing the program in context• Acceptance testing: system testing designed
to show that the program meets its functional requirements
Fall 2007 CS 225
Approaches to Testing
• Black-box testing: tests the item based on its interfaces and functional requirements
• White-box testing: tests the software with the knowledge of its internal structure
Fall 2007 CS 225
Preparations for Testing• A test plan should be developed early in the
design phase– Aspects of a test plan include deciding how the
software will be tested, when the tests will occur, who will do the testing, and what test data will be used
• If the test plan is developed early, testing can take place concurrently with the design and coding
• A good programmer practices defensive programming and includes code to detect unexpected or invalid data
Fall 2007 CS 225
Testing Methods
• Most of the time, you will test program systems that contain collections of classes, each with several methods
• Leave a trace of execution by displaying the method name as you enter it
• Display values of all input parameters upon entry to a method
Fall 2007 CS 225
Testing Methods (continued)
• Display the values of any class attributes that are accessed by this method
• Display the values of all method outputs after returning from a method
• Plan for testing as you write each module rather than after the fact
Fall 2007 CS 225
Developing the Test Data
• Test data should be specified during the analysis and design phases for the different levels of testing: unit, integration, and system– You should test both good data and bad
data– Check special cases called boundary
conditions
Fall 2007 CS 225
White- vs. Black-box Testing
• In black-box testing, we are concerned with the relationship between the unit inputs and outputs– There should be test data to check for all expected
inputs as well as unanticipated data
• In white-box testing, we are concerned with exercising alternative paths through the code– Test data should ensure that all if statement
conditions will evaluate to both true and false
Fall 2007 CS 225
Why do Testing?
• Normally testing is done by– The programmer– Other members of the software team who
did not code the module being tested– Final users of the software product
Fall 2007 CS 225
Who does the Testing?
• Programmers are often blind to their own oversights
• Companies also have quality assurance organizations that verify that the testing process is performed correctly
• In extreme programming, programmers work in pairs where one writes the code and the other writes the tests
Fall 2007 CS 225
When to test?
• Start testing as early as you can– don't wait until the coding is complete
• It may be difficult to test a method or class that interacts with other methods or classes
Fall 2007 CS 225
Stubs
• A replacement for a method that has not yet been implemented or tested is called a stub
• A stub has the same header as the method it replaces, but its body only displays a message indicating that the stub was called – It may need a fixed return value
Fall 2007 CS 225
Drivers
• A driver program declares any necessary object instances and variables, assigns values to any of the method’s inputs, calls the method, and displays the values of any outputs returned by the method
• You can put a main method in a class to serve as the test driver for that class’s methods
Fall 2007 CS 225
Assertions and Loop Invariants
• Assertions: logical statements about a program that are claimed to be true; generally written as a comment
• Preconditions and postconditions are assertions
• A loop invariant is an assertion– Helps prove that a loop meets it specification– True before loop begins, at the beginning of each
repetition of the loop body, and just after loop exit
Fall 2007 CS 225
Assertions and Loop Invariants Example
Fall 2007 CS 225
Assertions in Java
• Java has an assert statement which can take two forms
1. assert <boolean expression>;• Results in an AssertionError if the boolean
expression is ever false
2. assert <boolean expression> : <expression>;• The expression is printed as part of the
AssertionError message.
Fall 2007 CS 225
Using Assertions in Java
• Activate assertion checking with a command-line option to the interpreterjava -ae <class name>
Fall 2007 CS 225
Efficiency of Algorithms
• Can characterize a program by how the execution time or memory requirements increase as a function of increasing input size– Big-O notation
• A simple way to determine the big-O of an algorithm or program is to look at the loops and to see whether the loops are nested
Fall 2007 CS 225
Algorithm Efficiency• Consider:
• First time through outer loop, inner loop is executed n-1 times; next time n-2, and the last time once.
• So we have – T(n) = 3(n – 1) + 3(n – 2) + … + 3 or– T(n) = 3(n – 1 + n – 2 + … + 1)
Fall 2007 CS 225
Algorithm Efficiency
• We can reduce the expression in parentheses to:– n x (n – 1) / 2
• So, T(n) = 1.5n2 – 1.5n • This polynomial is zero when n is 1. For
values greater than 1, 1.5n2 is always greater than 1.5n2 – 1.5n
• Therefore, we can use 1 for n0 and 1.5 for c to conclude that T(n) is O(n2)
Fall 2007 CS 225
Efficiency of Algorithms