Program Correctness and Efficiency - PowerPoint PPT Presentation

1 / 44
About This Presentation
Title:

Program Correctness and Efficiency

Description:

Structured walkthrough: designer must explain the algorithm to other team ... test program systems that contain collections of classes, each with several methods ... – PowerPoint PPT presentation

Number of Views:69
Avg rating:3.0/5.0
Slides: 45
Provided by: phili3
Category:

less

Transcript and Presenter's Notes

Title: Program Correctness and Efficiency


1
Program Correctness and Efficiency
  • Chapter 2

2
Chapter Objectives
  • To understand the differences between the three
    categories of program errors
  • To understand the effect of an uncaught exception
    and why you should catch exceptions
  • To become familiar with the Exception hierarchy
    and the difference between checked and unchecked
    exceptions
  • To learn how to use the try-catch-finally
    sequence to catch and process exceptions
  • To understand what it means to throw an exception
    and how to throw an exception in a method

3
Chapter Objectives (continued)
  • To understand the different testing strategies
    and when and how they are performed
  • To learn how to write special methods to test
    other methods and classes
  • To become familiar with debugging techniques and
    debugger programs
  • To be introduced to the process of program
    verification and the use of assertions and loop
    invariants
  • To understand the meaning of big-O notation and
    how it is used to analyze an algorithms
    efficiency

4
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 removing defects

5
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
  • Some common syntax errors include
  • Omitting or misplacing braces
  • Performing an incorrect type of operation on a
    primitive type value
  • Invoking an instance method not defined,
  • Not declaring a variable before using it
  • Providing multiple declarations of a variable

6
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 error
  • Null pointer exceptions

7
Run-time Errors or Exceptions (continued)
8
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

9
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

10
The Class Throwable
  • Throwable is the superclass of all exceptions
  • All exception classes inherit the methods of
    throwable

11
The Class Throwable (continued)
12
Checked and Unchecked Exceptions
  • Two categories of exceptions checked and
    unchecked
  • Checked exception normally not due to programmer
    error and is beyond the control of the programmer
  • Unchecked exception may result from
  • Programmer error
  • Serious external conditions that are
    unrecoverable

13
Checked and Unchecked Exceptions (continued)
14
Catching and Handling Exceptions
  • When an exception is thrown, the normal sequence
    of execution is interrupted
  • Default behavior
  • 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

15
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

16
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

17
Handling Exceptions to Recover from Errors
  • Exceptions provide the opportunity to
  • Recover from errors
  • Report errors
  • User error is a common source of error and should
    be recoverable
  • 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

18
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

19
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 throw the exception in the lower-level
    method, using a throw statement
  • The throws clause is useful if a higher-level
    module already contains a catch clause for this
    exception type

20
Throwing Exceptions (continued)
  • 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

21
Programming Style
  • 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

22
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)

23
Structured Walkthroughs
  • 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
  • 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

24
Levels and Types of 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
  • Unit testing checking the smallest testable
    piece of the software (a method or class)
  • Integration testing testing the interactions
    among units

25
Levels and Types of Testing (continued)
  • System testing testing the program in context
  • Acceptance testing system testing designed to
    show that the program meets its functional
    requirements
  • 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

26
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

27
Testing Tips for Program Systems
  • Most of the time, you will test program systems
    that contain collections of classes, each with
    several methods
  • If a method implements an interface, its
    specification should document input parameters
    and expected results
  • Carefully document each method parameter and
    class attribute using comments as you write the
    code
  • 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

28
Testing Tips for Program Systems (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

29
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
  • 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

30
Testing Boundary Conditions
  • When hand-tracing through an algorithm or
    performing white-box testing, you must exercise
    all paths
  • Check special cases called boundary conditions

31
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
  • Do not rely on programmers for testing as they
    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

32
Stubs
  • It may be difficult to test a method or class
    that interacts with other methods or classes
  • The replacement of 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

33
Drivers
  • A driver program declares any necessary object
    instances and variables, assigns values to any of
    the methods 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 classs methods

34
Using a Test Framework
  • A test framework is a software product that
    facilitates writing test cases, organizing the
    test cases into test suites, running the test
    suites, and reporting the results
  • A test framework often used for Java products is
    JUnit, an open-source product that can be used in
    a stand-alone mode and is available from junit.org

35
Debugging a Program
  • Debugging is the major activity performed by
    programmers during the testing phase
  • Testing determines if there is an error,
    debugging determines the cause of it
  • Debugging is like detective work
  • Inspect carefully the information displayed by
    your program
  • Insert additional diagnostic output statements in
    the method to determine more information

36
Using a Debugger
  • Debuggers often are included with IDEs
  • A debugger can execute your program incrementally
    rather than all at once
  • Single-step execution executes in increments as
    small as one program statement
  • Breakpoints are used to traverse large portions
    of code before stopping
  • The actual mechanics of using a debugger depend
    on the IDE that you are using

37
Using a Debugger (continued)
38
Reasoning about Programs 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

39
Efficiency of Algorithms
  • Difficult to get a precise measure of the
    performance of an algorithm or program
  • 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

40
Efficiency of Algorithms (continued)
41
Efficiency of Algorithms (continued)
42
Chapter Review
  • Three kinds of defects can occur in programs
  • Syntax errors
  • Run-time errors
  • Logic errors
  • All exceptions in the Exception class hierarchy
    are derived from a common superclass called
    Throwable
  • The default behavior for exceptions is for the
    JVM to catch them by printing an error message
    and a call stack trace and then terminating the
    program

43
Chapter Review (continued)
  • Two categories of exceptions checked and
    unchecked
  • A method that can throw a checked exception must
    either catch it or declare that it is thrown
  • throw statement throws an unchecked exception
  • Program testing is done at several levels
    starting with the smallest testable piece of a
    program called a unit
  • Integration testing once units are individually
    tested, they can then be tested together
  • System testing once the whole program is put
    together, it is tested as a whole

44
Chapter Review (continued)
  • Acceptance programming involves testing in an
    operational manner demonstrating its
    functionality
  • Black-box testing tests the item based on its
    functional requirements without knowledge of its
    internal structure
  • White-box testing tests the item using knowledge
    of its internal structure
  • Test drivers and stubs are tools used in testing
  • Test drivers exercise a method or class
  • Stubs stand in for called methods
  • Big-O notation determines the efficiency of a
    program
Write a Comment
User Comments (0)
About PowerShow.com