when an exceptional condition is detected an Exception object is created and throw statement is used to pass the Exception to a catch block or up the call stack
catching an exception
handling an exception that has been thrown to a try block
try block
a set of statements that includes at least one statement that can throw an exception
catch block
a set of statements meant to catch the exception(s) specified in the catch header that are called immediately following the statement that threw an exception in the try block
finally block
a set of statements that are executed after the try block or after the catch block if an exception is thrown
dynamic scope
the scope that changes at runtime. In java this happens using try/catch blocks with exception handling.
static scope
the scope defined by source code
dialog box
a window that can only be created from a top-level window.
top-level window
a window that can be created on its own.
checked exception
an exception that needs to either be caught in a try/catch block, or be in a method that throws the exception.
unchecked exception
an exception that doesn’t need to be caught.
method stack
A data structure that holds the current history of method calls.
Suppose you have a program that asks the user to input a string of no more than five letters. Describe the steps you’d need to take in order to design a StringTooLongException to handle cases where the user types in too many characters.
Suppose the following ExerciseExample program is currently executing the if statement in method2():
public class ExerciseExample {
public void method1(int M) {
try {
System.out.println("Entering try block");
method2( M );
System.out.println("Exiting try block");
} catch (Exception e) {
System.out.println("ERROR: " + e.getMessage());
}
} // method1()
public void method2(int M) {
if (M > 100)
throw new ArithmeticException(M + " is too large");
}
public static void main(String argv[]) {
ExerciseExample ex = new ExerciseExample();
ex.method1(500);
}
} // ExerciseExample
Draw a picture of the method call stack that represents this situation.
Consider again the ExerciseExample program. If the exception thrown were Exception rather than ArithmeticException, explain why we would get the following error message: java.lang.Exception must be caught, or it must be declared… .
Write a try/catch block that throws an Exception if the value of variable X is less than zero. The exception should be an instance of Exception and, when it is caught, the message returned by getMessage() should be “ERROR: Negative value in X coordinate.”
Look at the IntFieldTester program (Listing 10.6.5) and the IntField class definition (Listing 10.6.4). Suppose the user inputs a value that’s greater than 100. Show what the method call stack would look like when the IntField.getInt() method is executing the num > bound expression.
As a continuation of the previous exercise, modify the IntOutOfRangeException handler so that it prints the message call stack. Then show what it would print.
Define a subclass of RuntimeException named InvalidPasswordException, which contains two constructors. The first constructor takes no parameters and an exception thrown with this constructor should return “ERROR: invalid password” when its getMessage() is invoked. The second constructor takes a single String parameter. Exceptions thrown with this constructor should return the constructor’s argument when getMessage() is invoked.
Extend the IntField class so that it will constrain the integer JTextField to an int between both a lower and upper bound. In other words, it should throw an exception if the user types in a value lower than the lower bound or greater than the upper bound.
You’ll notice in IntField, Listing 10.6.4, that the upper bound is private. That means that you’ll need to use the parent getInt() method to check the upper bound, and you’ll only need to check the lower bound yourself. The size parameter of the IntField constructors specifies the number of characters that the field should show, and it has nothing to do with the value of the number in the field.
Design Issue: One of the preconditions for the InsertionSort() method (in Ch. 9) is that its array parameter not be null. Of course, this precondition would fail if the array were passed a null array reference. In that case, Java would throw a NullPointerException and terminate the program. Is this an appropriate way to handle that exception?
With respect to the previous exercise, suppose you decide that it is more appropriate to handle the NullPointerException by presenting an error dialog. Modify the method to accommodate this behavior.
Design Issue: Another possible way to design the sequentialSearch() method (in Ch. 9) would be to have it throw an exception when its key is not found in the array. Is this a good design? Explain.
