Programming & Debugging

1. Programming & Debugging

2. Key Programming Issues • Modularity • Modifiability • Ease of Use • Fail-safe programming • Style • Debugging

3. Modularity • Why? • Smaller pieces are easier to understand • Easier to isolate proper piece for debugging, modification • Good modules are easier to reuse • How? • Abstraction • Obiect-oriented Design

4. Modifiability • Why? • Programs are never static; problems change • Avoid reinventing the wheel as much as possible • How? • Good structure (classes & functions) • Named constants • Typedef (e.g. typedef float RealType;) • Good documentation!

5. Ease of Use • Why? • So it will be used • How? • Clear prompts for input • Echo the input • Clear output • Adapt program to user, not vice versa • See CPSC 222 for more!

6. Fail-Safe Programming • Why? • Input isn’t always what it should be (from users or otherwise) • How? • Validate input data (ensure preconditions satisfied) • Use assert to check preconditions and invariants (assertions)

7. Style • Why? • Good style addresses all the other issues! • Programs are also read by people • How? • Style guides vary • Pick one (the textbook guidelines are good) and be consistent! • Many of the “style” guidelines in the book would come under good modularity in my mind.

8. Issues of Style • Reasonable-sized methods • Private data members (inspectors/accessors & mutators as necessary) • Avoid global variables • Use void methods for side effects • Readability & Documentation

9. Readability & Documentation • Good (consistent!) use of indentation • Liberal use of blank space • Useful identifier names • Identify author/date on each file (use JavaDoc template) • Comment per class (what it provides) • Comment for any non-obvious data item (class member or local variable) • Comment per method (pre and post conditions, what it does, explain parameters) • Comment at important / tricky steps in function (e.g. invariants)

10. Debugging • Why? • Because there are bugs • How? • Compiler’s help (for syntax errors) • Output statements • IDE Debugger • Break • Watch • Step

11. 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

12. Types of Errors • Syntax Error • Runtime Error (or Exception) • Logic Error

13. Syntax Errors • Mistakes in grammar of the language • Detected by compiler; prevent successful compilation • Examples: • Omitting or misplacing braces or semicolons • 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

14. 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 • Integer diivision by zero • Array index out of bounds • Number format and Input mismatch error • Null pointer exceptions

15. Java Exceptions

16. Logic Errors • The program runs without error, but doesn’t do what was expected (in at least one case) • Examples: • Calculates the wrong answer • Does not halt • Ignores valid inputs or data

17. 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

18. 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

19. Throwable Exception Hierarchy

20. Methods of Throwable (Inherited by subclasses)

21. Checked and Unchecked Exceptions • Checked exception • Beyond control of programmer • Subclass of Exception (but not RuntimeException) • Unchecked exception may result from • Programmer error • Serious external conditions that are unrecoverable • Subclasses of RuntimeException

22. Example: Checked Exceptions

23. Exception Hierarchy Unchecked exceptions

24. Handling Exceptions • Unchecked exceptions (including errors) • These are considered unrecoverable • Programmers not “expected” to handle them (but expected not to cause them) • Checked exceptions • Due to external conditions, often recoverable

25. 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 and stack trace • The programmer may override the default behavior by • Enclosing statements in a try block • Processing the exception in a catch block

26. 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 • Finally (if provided) is executed after try block or catch block • Use this to “clean up” (e.g. close open files)

27. Try-catch-finally try { //statements that might cause exception } catch (EOFException ex){ //code for EOF Exception } catch(IOException ex){ //code for IO Exception } finally{ //code executed after try or catch code }

28. Handling Exceptions to Recover from Errors • Exceptions provide the opportunity to • Recover from errors (preferable, if possible) • Report errors • First matching Catch block (only) is executed • Match according to the type of exception • Compiler displays an error message if it encounters an unreachable catch clause • Example: IOException with no IO in try clause

29. Throwing Exceptions • If method doesn’t catch exception, it can throw it (to its caller) • Add a throws clause to the method header • Explicitly throw the exception, using a throw statement • The throws clause is useful if a higher-level module already contains a catch clause for this exception type

30. Throw statement • 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 • Throw statement useful for user-defined exceptions (e.g. item not found)

31. Catching Exceptions Example

32. Guidelines for Exceptions • 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