Friday, December 4, 2009

Solutions to Self-Study Exercises











[Page 505]

Solutions to Self-Study Exercises



Solution 10.1


  1. Integer.parseInt("26.2"); ==> NumberFormatException

  2. String s; s.indexOf('a'); ==> NullPointerException

  3. String s = "hello"; s.charAt(5); ==> StringIndexOutOfBoundsException


Solution 10.2

The unchecked exceptions are IndexOutOfBoundsException, NumberFormatException, and NullPointerException, because these are subclasses of RuntimeException. The others are checked exceptions.


Solution 10.3

An ArrayIndexOutOfBoundsException could be handled by the handlers in a, c, or d, because their classes are all superclasses of ArrayIndexOutOfBoundsException.

Solution 10.4

If Math.random() in MyClass2 returns 0.98 and then 0.44, the program will generate the following output:


0.98 is out of range


Note that because the out-of-range error occurs in method1(), method2() is not called at all.

Solution 10.5

If Math.random() in MyClass2 returns 0.98 and then 0.44, the following stack trace would be printed:


java.lang.ArithmeticException: 0.98 is out of range
at MyClass2.method1(MyClass2.java:3)
at MyClass2.main(MyClass2.java:15)


Solution 10.6

If Math.random() in MyClass2 returns 0.44 and then 0.98, the program will generate the following output:


Hello 0.44
0.98 is out of range


Solution 10.7

If Math.random() in MyClass2 returns 0.44 and then 0.98, the following stack trace would be printed:


java.lang.ArithmeticException: 0.98 is out of range
at MyClass2.method2(MyClass2.java:8)
at MyClass2.main(MyClass2.java:16)



[Page 506]
Solution 10.8

The divide-by-zero error in BadDivide occurs in the expression n/d in Method2(). It would generate the following stack trace:


java.lang.ArithmeticException: divide by zero
at BadDivide.method2(BadDivide.java:7)
at BadDivide.method1(BadDivide.java:3)
at BadDivide.main(BadDivide.java:13)


Solution 10.9

The following version of BadDivide.method2() will handle the divide-by-zero error itself:


public void method2 (int n, int d) {
try {
System.out.println(n / d);
} catch (ArithmeticException e) {
System.out.println(e.getMessage());
e.printStackTrace();
System.exit(0);
}
}


Solution 10.10

If someValue equals 1000, the code segment will print:


Entering try block
ERROR: 1000 is too large


Solution 10.11

If someValue equals 50, the code segment will print:


Entering try block
Exiting try block


Solution 10.12


try {
if (X < 0)
throw new Exception("ERROR: Negative value in X coordinate");
} catch (Exception e) {
System.out.println( e.getMessage() );
}




[Page 507]
Solution 10.13


  1. It depends. This is a computer game, so one way to handle this problem would be to generate a message into a log file and resume the game. If the GUI element is crucial to the game, it's hard to see how it could be successfully handled.

  2. It depends. You would have to decide whether it would be more harmful or dangerous to continue production than not.

  3. The program could report the security violation to the user and the system manager and then keep accepting user input.


Solution 10.14


public class FieldIsEmptyException extends Exception {
public FieldIsEmptyException () {
super("The input field is empty ");
}
}


Solution 10.15


public int getInt() {
int num = 0;
try {
String data = getText();
if (data.equals(""))
throw new FieldIsEmptyException();
num = Integer.parseInt( getText() );
if (num > bound)
throw new IntOutOfRangeException(bound);
} catch (FieldIsEmptyException e) {
System.out.println("Error: " + e.getMessage() );
} catch (NumberFormatException e) {
System.out.println("Error: You must input an integer. Please try again.");
} catch (IntOutOfRangeException e) {
System.out.println(e.getMessage());
return 0;
}
return num;
}













No comments: