Transcript Document

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 runtime 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 higherlevel module already contains a catch
clause for this exception type
Throw statement
• Can use a throw statement in a lowerlevel 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