1 CMPSCI 187 Computer Science 187 Introduction to Introduction to Programming with Data Structures Lecture 4 Program Correctness and Testing Announcements: OWL accounts should be accessible OWL accounts should be accessible First programming project will be up soon. First programming project will be up soon. Problems with EdLab accounts? Problems with EdLab accounts? Textbooks? Everybody have one? Textbooks? Everybody have one? CS Saturday CS Saturday

2 CMPSCI 187 Program Correctness and Efficiency l Lecture Follows Koffmann and Wolfgang: Chapter 2 l More or less…..

3 CMPSCI 187 Outline l Categories of program errors l Why you should catch exceptions The Exception hierarchy F Checked and unchecked exceptions The try - catch - finally sequence l Throwing an exception: F What it means F How to do it

4 CMPSCI 187 Outline (continued) l A variety of testing strategies l How to write testing methods l Debugging techniques and debugger programs l Program verification: assertions and loop invariants

5 CMPSCI 187 Program Defects and “Bugs” l An efficient program is worthless if it breaks or produces a wrong answer l Defects often appear in software after it is delivered l Testing cannot prove the absence of defects l It can be difficult to test a software product completely in the environment in which it is used l Debugging: removing errors l Testing: finding (and removing) defects

6 CMPSCI 187 Major Categories of Defects l Syntax and other in-advance errors F ---> compiler l Run-time errors and exceptions F ---> compiler l Logic Errors F ---> Us!

7 CMPSCI 187 Syntax Errors l Syntax errors: grammatical mistakes in a program l The compiler detects syntax errors F You must correct them to compile successfully l Some common syntax errors include: F Omitting or misplacing braces, parentheses, etc. F Misplaced end-of-comment F Typographical errors (in names, etc.) F Misplaced keywords l Java IS context sensitive: theCat and thecat are NOT the same.

8 CMPSCI 187 Semantic Errors l Semantic errors: may obey grammar, but violate other rules of the language l The compiler detects semantic errors F You must correct them to compile successfully l Some common semantic errors include: F Performing an incorrect operation on a primitive type value F Invoking an instance method not defined F Not declaring a variable before using it F Providing multiple declarations of a variable F Failure to provide an exception handler  Failure to import a library routine

9 CMPSCI 187 Run-time Errors or Exceptions l Run-time errors F Occur during program execution (run-time!) F Occur when the JVM detects an operation that it knows to be incorrect F Causes the JVM to throw an exception l Examples of run-time errors include F Division by zero F Array index out of bounds F Number format error F Null pointer exceptions

10 CMPSCI 187 Run-time Errors or Exceptions (continued)

11 CMPSCI 187 Example Last login: Mon Sep 18 23:58:12 on ttyp1 /tmp/CodeWarriorJava.command; exit Welcome to Darwin! [gimpy-cs-umass-edu:~] al% /tmp/CodeWarriorJava.command; exit cd /Users/al/Desktop/ExceptionExample java -cp.:/Users/al/Desktop/ExceptionExample/JavaClasses.jar ExceptionTest Exception in thread "main" java.lang.ArithmeticException: / by zero at ExceptionTest.main(ExceptionTest.java:11) logout [Process completed] import java.io.*; // Application that shows what happens when an exception is thrown public class ExceptionTest { public static void main(String args[]) { int num=100; int denom=0; int result = num/denom; System.out.println("And the result is: "+result);} }

12 CMPSCI 187 Logic Errors l A logic error is a programmer mistake in F the design of a class or method, or F the implementation of an algorithm l Most logic errors F Are not syntax or semantic errors: get by the compiler F Do not cause run-time errors F DO cause the program to operate incorrectly…. F Thus they are difficult to find l Sometimes found through testing l Sometimes found by users

13 CMPSCI 187 Avoiding Logic Errors l Work from a precise specification l Strive for clarity and simplicity l Consider “corner” / extreme cases l Have reviews / walk-throughs: other eyes l Use library/published algorithms where possible l Think through pre/post conditions, invariants l Be organized and careful in general

14 CMPSCI 187 The Exception Class Hierarchy When an exception occurs, the first thing that happens is a new of a Java exception object l Different exception classes have different rules Throwable is the root superclass of the exception class hierarchy  Error is a subclass of Throwable  Exception is a subclass of Throwable  RuntimeException is a subclass of Exception

15 CMPSCI 187 The Class Throwable Throwable is the superclass of all exceptions l All exception classes inherit its methods Throwable Error AssertionError Exception RunTimeException Other Error Classes Checked Exception Classes Unchecked Exception Classes

16 CMPSCI 187 The Class Throwable (continued)

17 CMPSCI 187 The Exception Class Hierarchy Throwable is the superclass of all exception classes Error is for things a program should not catch  Example: OutOfMemoryError Exception is for things a program might catch  RuntimeException is for things the VM might throw H It can happen anywhere: e.g., any object access can throw NullPointerException H So not required to catch it F All others (checked exceptions) must be either: H Explicitly caught or H Explicitly mentioned as thrown by the method

18 CMPSCI 187 Exception Hierarchy Summary Error: don’t catch, unchecked l Exception:  RuntimeException: H (Usually) don’t catch, unchecked F All others: checked, so must H Catch, or H Mention they may be thrown

19 CMPSCI 187 Checked and Unchecked Exceptions unchecked checked

20 CMPSCI 187 Some Common Unchecked Exceptions l ArithmeticException F Division by zero, etc. l ArrayIndexOutOfBoundsException l NumberFormatException F Converting a “bad” string to a number l NullPointerException l NoSuchElementException F No more tokens available

21 CMPSCI 187 Catching and Handling Exceptions l When an exception is thrown, the normal sequence of execution is interrupted Default behavior,i.e., no handler (no try-catch block) F Program stops F JVM displays an error message l The programmer may provide a handler  Enclose statements in a try block  Process the exception in a catch block

22 CMPSCI 187 Simple Example l If exceptions are not handled by your program, it will terminate abnormally if one occurs. public class divideByZero { public static void main (String[] args) { int num = 25; int denom = 0; System.out.println(num/denom); } }//end divideByZero Divide by zero

23 CMPSCI 187 Anatomy of an Exception _exceptionOccurred: java.lang.ArithmeticException (/ by zero) java.lang.ArithmeticException: / by zero at divideByZero.main(divideByZero.java:5) at com.apple.mrj.JManager.JMStaticMethodDispatcher.run(JMAWTContextImpl.java:706) at java.lang.Thread.run(Thread.java:473) The ‘class’ of the exception being thrown….ArithmeticException 2. The reason for the exception….divide by 0 3. A ‘call’ stack trace…how did we get here? Exceptions are objects…instances of classes Methods of the Exception Class being thrown:  getMessage(): returns a string explaining the reason  printStackTrace: prints the stack trace

24 CMPSCI 187 Handling the Exception public class divideByZero { public static void main (String[] args) { int num = 25; int denom = 0; try { System.out.println(num/denom); } catch (ArithmeticException E) { //here's what to do if the exception occurs if (denom==0) System.out.println("Error: attempt to divide by zero - program terminates"); else System.out.println("Error: numeric problems - program terminates"); System.exit(0); }//end of exception handler } }//end divideByZero “try” block “catch” block The instance of the exception class that contains information about this exception.

25 CMPSCI 187 Exceptions are Objects public class divideByZero { public static void main (String[] args) { int num = 25; int denom = 0; try { System.out.println(num/denom); } catch (ArithmeticException E) { //here's what to do if the exception occurs if (denom==0) {System.out.println("Arithmetic exception - program terminates"); System.out.println("Reason: " + E.getMessage()); System.out.println("Dump of execution stack follows:"); E.printStackTrace();} else System.out.println("Error: numeric problems - program terminates"); System.exit(0); }//end of exception handler } }//end divideByZero

26 CMPSCI 187 Here’s what we get Arithmetic exception - program terminates Reason: / by zero Dump of execution stack follows: java.lang.ArithmeticException: / by zero at divideByZero.main(divideByZero.java:6) at com.apple.mrj.JManager.JMStaticMethodDispatcher.run(J MAWTContextImpl.java:706) at java.lang.Thread.run(Thread.java:473)

27 CMPSCI 187 The try Statement try { statement list….. } catch (exception-class1 variable1) { statement list….. } catch (exception-class2 variable2) { statement list….. } ………………….etc. Each ‘catch’ clause handles a particular kind of exception that may get thrown from the try block Exceptions listed in order from lowest subclass to highest superclass

28 CMPSCI 187 How to get in Trouble public class test { public static void main (String[] args) { try { int k=5; int i = 40; int j=0; System.out.println(i/j); } catch (ArithmeticException exception) { System.out.println("Caught you"); } System.out.println(" "+k); } BEWARE: this program doesn’t work. k defined and initialized inside try block k used outside try block. k is undefined variable - program won’t compile! File “test.java”; Line 19 Error: Undefined variable: k

29 CMPSCI 187 Next Try! public class test { public static void main (String[] args) { int k; try { k=5; int i = 40; int j=0; System.out.println(i/j); } catch (ArithmeticException exception) { System.out.println("Caught you"); } System.out.println(" "+k); } BEWARE: this program doesn’t work. k defined outside try block and initialized inside. k used outside try block. k is possibly uninitialized variable - program won’t compile! File “test.java”; Line 19 Error: Variable k may not have been initialized.

30 CMPSCI 187 Finally - One that Works! public class test { public static void main (String[] args) { int k=0; try { k=5; int i = 40; int j=0; System.out.println(i/j); } catch (ArithmeticException exception) { System.out.println("Caught you"); } System.out.println(" Value of k is: "+k); } RULE: variables in a try block that are to be used elsewhere in the program MUST be declared and initialized outside of the try block. OUTPUT: Caught you Value of k is: 5

31 CMPSCI 187 Exception Propagation l If an exception is not caught and handled where it occurs, it is propagated to the calling method. l A invokes B invokes C: A B C exception thrown here; no ‘catch’ clause. TERMINATE and go to invoking method. no ‘catch’ clause here, either. TERMINATE and transfer to invoking method B invoked within a try block in A; therefore exception is caught here.

32 CMPSCI 187 Another try-catch example String name = args[0]; try { InputStream in = new FileInputStream(name);... } catch (FileNotFoundException e) { System.out.printf( “File not found: %s%n”, name); } catch (Throwable e) { System.err.println("Exception!"); e.printStackTrace(System.err); }

33 CMPSCI 187 Uncaught Exceptions l Uncaught exception exits VM with a stack trace l The stack trace shows F The sequence of method calls H Starts with throwing method  Ends at main

34 CMPSCI 187 The try-catch Sequence l Avoiding uncaught exceptions  Write a try-catch to handle the exception F Point: prevent ugly program termination! H Unpleasant for user H Worse, may leave things messed up / “broken” catch block is skipped if no exception thrown within the try block

35 CMPSCI 187 Handling Exceptions to Recover from Errors l Exceptions provide the opportunity to F Report errors F Recover from errors l User errors common, and should be recoverable l Most closely enclosing handler that matches is the one that executes F A handler matches if its class includes what’s thrown Compiler displays an error message if it encounters an unreachable catch clause

36 CMPSCI 187 The finally block On exception, a try is abandoned l Sometimes more actions must be taken F Example: Close an output file Code in a finally block is always executed  After the try finishes normally, or  After a catch clause completes finally is optional

37 CMPSCI 187 Example of finally block try { InputStream ins =...;... ins.read();... } catch (EOFException e) { System.err.println(“Unexpected EOF”); e.printStackTrace(); System.exit(17); } finally { if (ins != null) ins.close(); }

38 CMPSCI 187 Throwing Exceptions l Lower-level method can pass exception through F Can be caught and handled by a higher-level method F Mark lower-level method H Say it may throw a checked exception  Mark by throws clause in the header F May throw the exception in the lower-level method  Use a throw statement l Particularly useful if calling module already has a handler for this exception type

39 CMPSCI 187 Throwing Exceptions (2) Use a throw statement when you detect an error l Further execution stops immediately: F Goes to closest suitable handler F May be a number of level of calls earlier  Does execute any finally blocks in the middle

40 CMPSCI 187 Example of Throwing an Exception /** adds a new entry or changes an old one name the name to create/update number the (new) number the previous number, a String IllegalArgumentException if the number * is not in phone number format */ public String addOrChangeEntry( String name, String number) { if (!isPhoneNumberFormat(number)) { throw new IllegalArgumentException( “Invalid phone number: “ + number); }... }

41 CMPSCI 187 Another Example public void accessLocalFile (String askingUser) throws CertificateException {... if (user’s secure socket certificate bad) { throw new CertificateException(reason); }... }

42 CMPSCI 187 Programming Style l You can always avoid handling exceptions: F Declare that they are thrown, or F Throw them and let them be handled farther back l But: usually best to handle instead of passing l Guidelines: 1. If recoverable here, handle here 2. If checked exception likely to be caught higher up declare that it can occur using a throws clause 3. Don’t use throws with unchecked exceptions Use javadoc comment when helpful

43 CMPSCI 187 Programming Style (2) l Omits arbitrary patches of code Can leave things in “broken” state l No warning to user l Leads to hidden, difficult to detect, defects Don’t do this! try {...} catch (Throwable e) { }

44 CMPSCI 187 Handling Exceptions in Phone Dir Example In loadData : FileNotFoundException from FileReader constructor IOException from readLine In PDConsoleUI : InputMismatchException from nextInt In addOrChangeEntry : IllegalArgumentException for empty String

45 CMPSCI 187 Creating Our Own Exceptions l An exception can be defined by a programmer. l An exception can be thrown, when the situation warrants, by using the throw statement: l throw exception_variable l This starts exactly the same sequence of events that occurs when a system exception is detected. l Throw statement transfers control to the applicable catch clause if the throw statement was within a try block. l Otherwise, the exception propagates to the calling method.

46 CMPSCI 187 Our Own Exception class DivByTwo extends Exception { public DivByTwo(String message) { super(message); } Name of exception l Let’s do an example similar to our divide by 0 example earlier. l To this example, we want to add our own exception that responds to an attempt to divide by 2 (a dastardly act!). l We’ll rewrite the whole example to make it easier to understand.

47 CMPSCI 187 The Operations Class public class Operations { public Operations() {}; public int div (int i, int j) throws DivByTwo { if (j==2) throw new DivByTwo("You worm, you're dividing by 2 again, aren't you?"); return i/j; } public int mult(int i, int j) { return i*j; }

48 CMPSCI 187 The Test Program public class divideByTwo { public static void main (String[] args) { Operations test = new Operations(); try { System.out.println(test.mult(6,4)); System.out.println(test.div(10,2)); System.out.println(test.div(10,0)); } catch (ArithmeticException exception) { //here's what to do if the exception occurs System.out.println("Arithmetic exception - program ends"); System.out.println("Reason: " + exception.getMessage()); System.out.println("Dump of execution stack follows:"); exception.printStackTrace(); System.exit(0); }//end of exception handler catch (DivByTwo exception) { System.out.println(exception.getMessage()); exception.printStackTrace(); }//end of exception handler System.out.println("That's all folks!"); }//end Main }//end divideByTwo

49 CMPSCI 187 The Output 24 You worm, you're dividing by 2 again, aren't you? DivByTwo: You worm, you're dividing by 2 again, aren't you? at java.lang.Throwable. (Throwable.java:88) at java.lang.Exception. (Exception.java:53) at DivByTwo. (DivByTwo.java:5) at Operations.div(Operations.java:8) at divideByTwo.main(divideByTwo.java:5) at com.apple.mrj.JManager.JMStaticMethodDispatcher.run (JMAWTContextImpl.java:706) at java.lang.Thread.run(Thread.java:473) That's all folks! 1. The ‘class’ of the exception being thrown….DivByTwo 2. The reason for the exception….dividing by 2 3. A ‘call’ stack trace…how did we get here? 12 3

50 CMPSCI 187 Testing Programs l A program with F No syntax/semantic errors, and F No run-time errors, F May still contain logic errors l “Best” case is logic error that always executes F Otherwise, hard to find! l Worst case is logic error in code rarely run Goal of testing: Test every part of the code, on “good” and “bad”/”hard” cases

51 CMPSCI 187 Structured Walkthroughs l Most logic errors: F Come from the design phase F Result from an incorrect algorithm l Logic errors sometimes come from typos that do not cause syntax, semantic, or run-time errors  Famous: FORTRAN: DO 10 1 = l One way to test: hand-trace algorithm before implementing! l Thus: Structured Walkthroughs

52 CMPSCI 187 Structured Walkthroughs (2) The Designer: l Explains the algorithm to other team members l Simulate its execution with them looking on The Team: l Verifies that it works l Verifies that it handles all cases Walkthroughs are helpful, but do not replace testing!

53 CMPSCI 187 Testing Defined l Testing: F Exercising a program under controlled conditions F Verifying the results l Purpose: detect program defects after F All syntax/semantic errors removed F Program compiles l No amount of testing can guarantee the absence of defects in sufficiently complex programs

54 CMPSCI 187 Levels of Testing l Unit testing: checking the smallest testable piece F A method or class l Integration testing: F The interactions among units l System testing: testing the program in context l Acceptance testing: system testing intended to show that the program meets its functional requirements

55 CMPSCI 187 Some Types of Testing l Black-box testing: F Tests item based only on its interfaces and functional requirements F Assumes no knowledge of internals l White-box testing: F Tests with knowledge of internal structure

56 CMPSCI 187 Preparing to Test l Develop test plan early, in the design phase F How to test the software F When to do the tests F Who will do the testing F What test data to use l Early test plan allows testing during design & coding l Good programmer practices defensive programming F Includes code to detect unexpected or invalid data

57 CMPSCI 187 Testing Tips for Program Systems l Program systems contain collections of classes, each with several methods l A method specification should document F Input parameters F Expected results l Carefully document (with javadoc, etc.): F Each method parameter F Each class attribute (instance and static variable) F As you write the code!

58 CMPSCI 187 Testing Tips for Program Systems (2) Trace execution by displaying method name as you enter a method: public static final boolean TRACING = true;... public int computeWeight (...) { if (TRACING) { trace.printf(“Entering computeWeight“); }... }

59 CMPSCI 187 Testing Tips for Program Systems (3) Display values of all input parameters on entry: public int computeWeight (float volume, float density) { if (TRACING) { trace.printf(“Entering computeWeight“); trace.printf(“volume = %f, “, volume); trace.printf(“density = %f%n“, density); }... }

60 CMPSCI 187 Testing Tips for Program Systems (4) l Display values of any class attributes (instance and static variables) accessed by the method l Display values of all method outputs at point of return from a method l Plan for testing as you write each module, F Not after the fact!

61 CMPSCI 187 Developing Test Data l Specify test data during analysis and design F For each level of testing: unit, integration, and system l Black-box testing: unit inputs  outputs F Check all expected inputs F Check unanticipated data l White-box testing: exercise all code paths F Different tests to make each if test (etc.) true and false F Called coverage

62 CMPSCI 187 Developing Test Data (2) l Helpful to do both black- and white-box testing l Black-box tests can be developed early since they have to do with the unit specification l White-box tests are developed with detailed design or implementation: need code structure

63 CMPSCI 187 Testing Boundary Conditions l Exercise all paths for F Hand-tracing in a structured walkthrough F Performing white-box testing l Must check special cases: boundary conditions l Examples: F Loop executes 0 times, 1 time, all the way to the end F Item not found

64 CMPSCI 187 Who does the testing? l Normally testing is done by F The programmer F Team members who did not code the module F Final users of the product l Programmers often blind to their own oversights l Companies may have quality assurance groups l Extreme programming: programmers paired F One writes the code F The other writes the tests

65 CMPSCI 187 Stubs for Testing l Hard to test a method or class that interacts with other methods or classes l A stub stands in for a method not yet available l The stub: F Has the same header as the method it replaces F Body only displays a message that it was called l Sometimes you need to synthesize a reasonable facsimile of a result, for the caller to continue

66 CMPSCI 187 Drivers A driver program: l Declares necessary instances and variables l Provides values for method inputs l Calls the method l Displays values of method outputs A main method in a class can serve as a driver to test the class’s methods

67 CMPSCI 187 Regression Testing l Once code has passed all initial tests, it is important to continue to test regularly l Environment and other changes  “software rot” l A regression test is designed to: F Catch any “regression” or decay in the software F Insure old functionality works in face of enhancement F Alert earlier to any issues arising from other changes l Regression testing eased by a testing framework

68 CMPSCI 187 Using a Testing Framework Testing framework: software that facilitates: F Writing test cases F Organizing the test cases into test suites F Running the test suites F Reporting the results

69 CMPSCI 187 JUnit l A Java testing framework l Open-source product l Can be used stand-alone or with an IDE Available from junit.org

70 CMPSCI 187 JUnit Example import junit.framework.*; public class TestDirectoryEntry extends TestCase { private DirectoryEntry tom; private DirectoryEntry dick; private DirectoryEntry tom2; public void setUp () { tom = new DirectoryEntry(“Tom”, “...”); dick = new DirectoryEntry(“Dick”, “...”); tom2 = new DirectoryEntry(“Tom”, “...”); }

71 CMPSCI 187 JUnit Example (2) public void testTomCreate () { assertEquals(tom.getName(), “Tom”); assertEquals(tom.getNumber(), “...”); } public void testTomEqualsDick () { assertFalse(tom.equals(dick)); assertFalse(dick.equals(tom)); }

72 CMPSCI 187 JUnit Example (3) public void testTomEqualsTom () { assertTrue(tom.equals(tom)); assertTrue(tom.equals(tom2)); assertTrue(tom2.equals(tom)); } public void testSetNumber () { dick.setNumber(tom.getNumber()); assertEquals(tom.getNumber(),dick.getNumber()); }

73 CMPSCI 187 Integration Testing l Larger components: collection of classes l Done with smaller collection, then larger ones l Drive with use cases: scenarios with F Sample user inputs F Expected outputs F Can be challenging to automate

74 CMPSCI 187 Debugging a Program Debugging: the major activity during the testing phase l Testing determines that there is an error l Debugging determines the cause l Debugging is like detective work: logical deduction F Inspect all program output carefully F Insert additional output statements to find out more F Use breakpoints to examine world... at carefully selected points

75 CMPSCI 187 Using a Debugger l Debuggers often are included with IDEs l Debugger supports incremental program execution l Single-step execution provides increments as small as one program statement (or even one instruction) l Breakpoints traverse larger portions of code at once l Details depend on the specfic IDE Key to debugging: Think first! Think a lot! l Also: try to split possible error sources in half with each investigation

76 CMPSCI 187 Reasoning about Programs: Assertions and Loop Invariants l Assertions: F Logical statements about program state F Claimed to be true F At a particular point in the program  Written as a comment, OR use assert statement l Preconditions and postconditions are assertions l Loop invariants are also assertions

77 CMPSCI 187 Reasoning about Programs: Loop Invariants A loop invariant: F Helps prove that a loop meets it specification F Is true before loop begins F Is true at the beginning of each iteration F Is true just after loop exit Example: Sorting an array of n elements Sorted(i): Array elements j, for 0 ≤ j < i, are sorted Beginning: Sorted(0) is (trivially) true Middle: We insure initial portion sorted as we increase i End: Sorted(n): All elements 0 ≤ j < n are sorted