Programming & Debugging

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

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

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!

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!

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)

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.

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

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)

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

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

Types of Errors Syntax Error Runtime Error (or Exception) Logic Error

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

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

Java Exceptions

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

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

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

Throwable Exception Hierarchy

Methods of Throwable (Inherited by subclasses)

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

Example: Checked Exceptions

Exception Hierarchy Unchecked exceptions

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

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

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)

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 }

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

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

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)

Catching Exceptions Example

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