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

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-finallytry { //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