213
Exceptions
Advanced COMP Object-oriented Programming
Weve seen that exceptions generally arise from input/resource failures. Lecture 18
Exceptions
Semantic coding errors (bugs) can go unnoticed until some input is of the wrong form (ArithmeticException), or until some resource isnt available (NullPointerException, ArrayIndexOutOfBoundsException). When this happens, a RuntimeException is thrown. These are generally unforeseeable (because they arise from bugs).
(Dubuffet )
Runtime Exceptions
The best way of recovering from these is to put a try-catch block at the top level (e.g., in the main() method) with a general error message: public static void main(String[] args) { try { // all the code } catch (RuntimeException re) { // report the error // exit gracefully } }
Other Exceptions
There are other subclasses of Exception (but not of RuntimeException) that are useful for other specic kinds of input/resource failure. For example, the IOException class signals that an I/O exception of some sort has occurred. This class has even more specic subclasses that include: FileNotFoundException MalformedURLException RemoteException
Checked Exceptions
These exceptions are not expected in the normal running of the Java interpreter. They signal resource errors (e.g., disk errors, unexpected user-input) that the programmer cannot ignore. They are treated very differently from the unchecked exceptions: whenever it is possible that a method might throw one of these exceptions, the programmer must either catch them (in a try-catch block), or advertise the fact that the method might throw one of these exceptions. These are called checked exceptions . . . and the compiler will check that programmers either catch or advertise.
Checked vs Unchecked
NB: unchecked = sublass of RuntimeException checked = not a subclass of RuntimeException
Advertising Exceptions
Unchecked exceptions must either be caught (handled) or advertised. For example, the class java.io.BufferedInputStream has the following method: public int read() throws IOException { ... } (which reads Input values (from keyboard, lestore, network connection, etc.) Any method that calls this method must either catch any IOExceptions, or advertise that it may throw such exceptions (in the same way that read() itself advertises this). }
For Example: Catching
Heres a method that calls read() and catches any IOException that might be thrown. public int readInt(BufferedInputStream b) { try { return b.read(); } catch (IOException ioe) { return -1; }
(For example, the program that uses this method might take a value of -1 as an indication of an error.)
For Example: Passing the Buck
Heres a method that doesnt catch IOExceptions, but passes them on. public int readInt(BufferedInputStream b) throws IOException { return b.read(); } Now any method that calls this method will either have to catch any IOExceptions, or advertise that they may throw IOExceptions.
Decisions, Decisions, . . .
Choosing which of these options (catching or advertising) to follow is a design decision. One should try to identify the most appropriate place to handle exceptions. There should be enough information to: formulate a meaningful error-message for the user; and make a reasonable decision as to whether, and how, to carry on.
Decisions, Decisions, . . .
The Parser
As a rule of thumb: If an exception is to be caught, it should be caught as deep down in the method-call stack as possible (i.e., as close to the top-level, or main() method as possible). Well look at an example from the Parser.java le from the practical.
Parser.java contains one class, Parser, which contains just one public method: in class Parser public Prop parse(String s) { ... } This method reads through the given string and, if the string is a well-formed term of propositional logic, constructs an instance of Prop that represents that term. But what if the string is not well-formed?
Decisions, Decisions, . . .
Option 1
Returning special values (such as null or -1) for special cases is a standard practice:
If the string that is passed to the parse() method is not well-formed, there are two fairly general options:
1 2
nd index of elt in array vals public int find(int elt, int[] vals) { for (int i=0; i < vals.length; i++) {
return null throw an exception }
if (vals[i] == elt) return i; // if were here, elt not found return -1; } -1 cant be an index of an array
Option 1
Option 2
This method searches an array for a given element; if the element is found in the array, it returns the index at which the element was found; otherwise, it returns -1. Thus, a result of -1 indicates that the element doesnt occur in the array. The danger here is that this is an implicit convention, one that any user of the find() method should be aware of (so it should be clearly documented).
For this option (the one we shall follow), we need to decide: what kind of exception to throw; where to throw such an exception; where (if at all) to catch such exceptions As to what kind, well create our own kind. . . .
Class ParseException
public class ParseException extends Exception { public ParseException(String s) { super(s); } public String getMessage() { return "Parse error: " + super.getMessage(); } } Inheriting Exception functionality Overriding the method in class Exception This is a way of calling the method being overridden
Notes
The superclass, Exception, provides most of what we need (the functionality of throwing, catching, etc.) We simply override the Exception.getMessage() method by adding Parse error: to the start of the error message. (the getMessage() method returns the string that is given as a parameter to the constructor) Because this class is subclass a of Exception, we effectively inherit all the Java interpreters mechanisms for throwing this kind of exception.
Where to Throw ParseExceptions?
Reading Operator Names
if (s.equals("and")) { return Operators.AND; } if (s.equals("or")) { return Operators.OR; } if (s.equals("implies")) { return Operators.IMPLIES; } // else throw new ParseException( "Expected one of and, or, or implies"); If the input is not what is expected, a ParseException is thrown.
Parser has only one public method, and 14 private methods that perform tasks such as reading variable names reading operator names reading white space, etc. Most of these functions could (and do) throw an exception if the input is not of the expected form. For example the following is from a method to read an operator name:
Where to Catch ParseExceptions?
The only public method in Parser is parse(); all of the private methods that throw exceptions must, ultimately have been called by this method. The user of this method might be entering terms to be parsed from the command line, or from a GUI. We dont know where to print out the error message, so it doesnt make sense to catch exceptions here. Instead, we pass the buck: public Prop parse(String s) throws ParseException { ... }
Catching at the Top Level
Now ParseExceptions can be caught at (or closer to) the top level of whatever application uses the parser. For example, in a main method, having set up a BufferedReader br:
in a main method Parser p = new Parser(); System.out.println( "Enter a term, q to quit"); String str = ""; while (! str.equals("q")) { str = br.readLine(); try { System.out.println(p.parse(str).toString()); } catch (ParseException pe) { System.out.println(pe.getMessage()); } }
Encapsulating Propositions?
The main problem with our implementation of propositions is that we can construct instances of Prop that do not correspond to any well-formed term (see Lecture 17). This problem concerns the adequacy of the representation.
Adequacy of Representation
Any implementation of an abstract data type represents the data elements in some way. For example, stacks may be represented by arrays and pointers; Boolean terms by tree structures. In Java, a data element will be represented by an instance of a class (e.g., Stack, Prop). The representation is said to be adequate if: every data element can be represented by some instance every instance represents a data element.
An Inadequate Constructor
The constructor for the class Prop is: Prop constructor public Prop(Operator o, Prop[] ps) { op = o; operands = ps; } This is clearly too generous: it allows the creation of instances that do not correspond to well-formed terms. We could test that the given array of Props contains the correct number of operands for the given operator (we omit the details. . . )
Modied Prop Constructor
BadTermException
public Prop(Operator o, Prop[] ps) throws BadTermException { if (ps is the right size for o) { op = o; operands = ps; } else { throw new BadTermException(); } }
public class BadTermException extends Exception { public String getMessage() { return "incorrect number of arguments"; } }
If we run the following program: public static void main(String[] args) throws BadTermException { Prop a, t; a = new Prop(Operators.makeVar("a"), new Prop[0]); t = new Prop(Operators.AND OP, new Prop[1...