Pages and 68 in [JN] conventions for using exceptions in Java. Chapter 8 in [EJ] guidelines for more effective use of exceptions.

Transcription

1 CS511, HANDOUT 12, 7 February 2007 Exceptions READING: Chapter 4 in [PDJ] rationale for exceptions in general. Pages and 68 in [JN] conventions for using exceptions in Java. Chapter 8 in [EJ] guidelines for more effective use of exceptions. 1 TWO USES FOR EXCEPTIONS Two broad situations where we use exceptions to report and react to: failures, typically producing erroneous or meaningless results. special cases, distinct from default cases but returning meaningful results. Although the distinction between the two is not always sharp, it is important to keep them separate and note their differences. Failures leading to erroneous results often require, but not always, program termination. These are errors which the program cannot recover from or which may undermine the integrity of other parts in the software installation. Special cases never require program termination. They correspond to boundary or limit conditions that are entirely expected by the programmer and require special handling separate from the common handling of the majority of default cases before allowing the program execution to continue and terminate gracefully. 2

2 TWO KINDS OF EXCEPTIONS The two uses of exceptions above roughly correspond to two different kinds: unchecked exceptions, typically used to report failures or serious errors likely leading to meaningless results. Use these exceptions for abnormal situations which it is hard to know where they come from. checked exceptions, typically used to report special cases or errors from which the program can recover gracefully. General guideline: Use unchecked exceptions for programming errors, from which recovery is impossible and continued execution will likely do more harm than good. Use checked exceptions for conditions from which the caller can reasonably be expected to recover. 3 TWO WAYS OF WRITING EXCEPTIONS Exceptions can be obtained in two different ways: library exceptions, many already written and tested in widespread practice, available for copying from the Java API. user-defined exceptions, written by the software developer according to need. General guideline: Favor the use of standard library exceptions. 4

3 Recommended Preferences: (1) checked over unchecked (2) subtype over supertype (3) library over user-defined (1) is debatable, (2) and (3) are not. 5 EXAMPLE: Three Specifications for the Factorial Function 1. An input x 0 is an error: public static int factorial (int x) // REQUIRES: x > 0 // EFFECTS: returns x! 2. An input x 0 returns a special value (not the factorial of a number): public static int factorial (int x) // EFFECTS: if x > 0 then returns x! else returns 0 3. An input x 0 throws an exception: public static int factorial (int x) // EFFECTS: if x > 0 then returns x! else returns an exception Question: Compare the three specifications. Which is to be preferred? 6

4 EXAMPLE: Three Implementations for the Factorial Function 1. On input x 0, there is no obligation to return anything: public static int factorial (int x) { // REQUIRES: x > 0 // EFFECTS: returns x! int fact = 1; while (x > 1) { fact = fact * x; x = x - 1; ; return fact; 2. On input x 0, the special value 0 is returned: public static int factorial (int x) { // EFFECTS: if x > 0 then returns x! else returns 0 if (x < 0) return 0; int fact = 1; while (x > 1) { fact = fact * x; x = x - 1; ; return fact; 7 3a. On input x 0, a library unchecked extension is thrown: public static int factorial (int x) { // EFFECTS: if x > 0 then returns x! else returns an exception if (x < 0) throw new IllegalArgumentException( x must be >= 0 ); int fact = 1; while (x > 1) { fact = fact * x; x = x - 1; ; return fact; 3b. On input x 0, a user-defined checked exception is thrown: public static int factorial (int x) throws NonPositiveException { /* a checked exception must be declared */ // EFFECTS: if x > 0 then returns x! else returns an exception if (x < 0) throw new NonPositiveException( x must be >= 0 ); int fact = 1; while (x > 1) { fact = fact * x; x = x - 1; ; return fact; While the unchecked exception in (3a) is optionally handled, the checked exception in (3b) must be handled. For handling of exceptions, see Sections and in [PDJ]. 8

5 EXAMPLE: Mixing Specifications and Exceptions Specification 3 on page 6 includes an exception, without naming one. We may need to be more specific and name the exceptions we want, as in the following postcondition: // EFFECTS: // if (array == null) // throws NullPointerException // else if (there is no i such that elem.equals(array[i])) // throws NoSuchElementException // else // return an i such that elem.equals(array[i]) 9 LIBRARY EXCEPTIONS FOR FAILURES AND SPECIAL CASES For Unrecoverable Failures (with unchecked exceptions) the VM has run out of memory (use OutOfMemoryError < VirtualMachineError < Error) a class file is corrupted and cannot be read (use ClassFormatError < LinkageError < Error) For Recoverable Failures? (with unchecked exceptions) the program has tried to read past the end of an array (use ArrayIndexOutOfBoundsException < IndexOutOfBoundsException < RuntimeException) For Recoverable Failures? Or Special Cases? (with checked exceptions) the end of a file is reached (use EOFException < IOException < Exception) a class file is missing (use ClassNotFoundException < Exception) 10

6 DISTINCTION BETWEEN FAILURE AND SPECIAL CASE The distinction is not always sharp and may depend on the context. Example: Is division by zero a failure or a special case? It depends. In a real-time navigational system that calls a procedure to compute the rate of descent, by dividing altitude by time elapsed, division by zero may be the result of an error with catastrophic consequences. This is a failure. Computing the average grade in a course where all the students are auditors, and none is registered for credit, division by zero is without grave consequences. The program should continue to compute other statistics about the course without problem. This is a special case. 11 EXERCISE: What kind of exception do you recommend to use in each of the following. Describe a situation that justifies your choice. 1. Someone tries to set the capacity of an object PassengerVehicle to a negative value. 2. A syntax error is found in a configuration file that an object uses to set its initial state. 3. A method that searches for a programmer-specified word in a string array cannot find any occurrence of the word. 4. A file provided to a method as input does not exit. 5. A file provided to a method as input exists, but security prevents the user from using it. 6. During an attempt to open a network connection to a remote server process, the remote machine cannot be contacted. 7. In the middle of a conversation with a remote server process, the network connection stops operating. 12

7 USER-DEFINED EXCEPTIONS FOR SPECIAL CASES Mostly Checked A common approach to handling special cases is to return special values. For example, lookup operations in the Java library are often designed so that the special value -1 is returned when expecting a positive integer, or the special reference null when expecting an object (a non-null reference). However, it becomes tedious to check the returned value every time, and it is easy to forget to do it. And sometimes it is not easy to think of a meaningful special value. 13 Example: User-Defined Checked Exception for a Special Case Suppose we have a class BirthdayBook with a lookup method with heading: Date lookup (String name) {... If the birthday book does not have an entry for the person whose name is given to the method lookup, we may decide to return a special value that cannot be a real date, e.g., 12/31/99. A cleaner approach is to throw a (user-defined checked) exception named NotFoundException which extends the library Exception : Date lookup (String name) throws NotFoundException {... if... // test for not found throw new NotFoundException ();... In this approach, the caller handles the exception with a catch clause, with no need for a special value or for the checking associated with it. 14

8 Example: User-Defined Checked Exception for a Special Case You are a bike dealer and need to validate a customer s order. Define a new class TooManyException that is a subclass of Exception, and if someone tries to order more bikes than you can ship, throw this checked exception: public class TooManyException extends Exception { public TooManyException () { super(); public TooManyException (String msg) { super(msg); public class BikeOrder { static void validateorder(string bikemodel,int quantity) throws TooManyException {... // perform some data validation, and if you do not like // the quantity for the specified model, do the following: throw new TooManyException ("Can not ship" + quantity + " bikes of the model " + bikemodel +); public class Order { try { BikeOrder.validateOrder ("Model-123", 50); // the next line will be skipped in case of an exception System.out.println ("The order is valid"); catch (TooManyException e) { txtresult.settext(e.getmessage()); 15 Example: User-Defined Unchecked Exception for a Special Case From [JC], page 244: /** A ChessMoveException is thrown when the user makes an illegal move */ public class ChessMoveException extends RuntimeException { public ChessMoveException () { super (); public ChessMoveException (String msg) { super(msg); Following custom, whenever subclassing the library RuntimeException or Exception in order to introduce a user-defined exception, at least one constructor without argument and one constructor with a single string argument are provided. 16

9 Example: Misusing Exceptions What does the following code do? (from [EJ] page 169) try { int i = 0; while (true) a[i++].f() ; catch (ArrayIndexOutofBoundsException e) { The infinite loop terminates by throwing, catching and ignoring an ArrayIndexOutofBoundsException when it attempts to access the first array element outside the bounds of the array. It is supposed to be equivalent to: for (int i = 0; i < a.length; i++) a[i].f(); 17 The exception-based idiom is a misguided attempt to improve performance based on the faulty reasoning that, since the VM checks the bounds of array accesses, the normal loop termination test (i < a.length) is redundant and should be avoided. However, because exceptions are designed for use only in exceptional circumstances, VM implementations rarely attempt to optimize their performance. On a typical machine, the exception-based idiom runs 70 times slower than the standard idiom when looping from 0 to 99. Moreover, the exception-based idiom is not guaranteed to work. Suppose the computation of f() in the body of the loop contains a bug that results in raising an ArrayIndexOutofBoundsException because of some unrelated array. If the standard idiom is used, the bug will generate an uncaught exception, resulting in immediate thread termination with an appropriate error message. If the exception-based idiom is used, the bug-related exception will be caught and misinterpreted as a normal loop termination. 18

10 REPLACING/ENFORCING PRECONDITIONS WITH EXCEPTIONS? A design issue is whether to use a precondition (in a method specification), and if so, whether to verify that it holds. Including a precondition in a method specification does not mean it has to be verified. On the contrary, preconditions are often used precisely because it would be too difficult to verify the property they define. Nonetheless, method callers do not like preconditions, which put the burden on them to make sure they do not call the method in a state violating the precondition. Hence, as a convenience to users, library methods tend to omit preconditions and, instead, throw exceptions when arguments are inappropriate. Sometimes this is not possible or recommended, i.e., it is better to keep a precondition and not replace it or to keep it without enforcing it with an exception. For example, in the Java standard library, the binary-search method of the Array class require that the array be sorted. But to verify that the array is indeed sorted takes linear time which is costlier than the logarithmic time of binary search! In this case, it is pointless to verify whether the array is sorted and, if it is not, to raise an exception; it simpler and more efficient to keep the precondition requiring the array be sorted. 19 Question: Should exceptions that are introduced to replace/enforce preconditions be checked exceptions or unchecked exceptions? If you have a precondition and you wish to replace (or enforce) it with an exception, it is preferable to throw an unchecked exception, rather than a checked exception. This is justified on the ground that callers cannot be expected to handle the exception, as they do not know enough to set up the method call properly in the first place. 20

11 CHECKED OR UNCHECKED EXCEPTIONS? The guideline proposed earlier in this handout was: If there is a choice, choose checked exceptions for special cases and unchecked exceptions for failures. But this is still too crude a guideline. Consider the design of a queue abstraction. Suppose you want your design to keep popping the queue until an exception is thrown. This is a special case, and so you choose a checked exception, which also requires that every call to the queue must be wrapped in a try-catch statement. Suppose some client wants to use the queue in a context in which, immediately prior to popping, the client tests whether the queue is empty and only pops if it is not. Nevertheless, this client still needs to wastefully wrap the call in a try-catch statement. Such a client would prefer an unchecked exception. 21 A more refined guideline is proposed in Sidebar 4.2, page 73, in [PDJ]: You should use an unchecked exception only if you expect that users will usually write code that ensures the exception will not happen, because there is a convenient and inexpensive way to avoid the exception, the context of use is local. Otherwise, you should use a checked exception. DEFENSIVE PROGRAMMING, EXCEPTIONS AND ASSERTIONS Look up appropriate pages in the index of [PDJ]. Also read pages in [JN]. 22