28:Propagate exceptions

Learning Objectives
After completing this session, you will be able to:
‰  Throw Exceptions
‰  Apply Throw and Throws clauses
‰  Propagate exceptions
Throwing Exceptions: The throw Keyword
Java allows you to throw exceptions (generate exceptions).
throw <exception object>;
An exception you throw is an object.
You have to create an exception object in the same way you create any other object.
Example:
throw new ArithmeticException(“testing...”);
Example: Throwing Exceptions
1 class ThrowDemo {
2 public static void main(String args[]){
3 String input = “invalid input”;
4 try {
5 if (input.equals(“invalid input”)) {
6 throw new RuntimeException("throw demo");
7 } else {
8 System.out.println(input);
9 }
10 System.out.println("After throwing");
11 } catch (RuntimeException e) {
12 System.out.println("Exception caught:" + e);
13 }
14 }
15 }
Propagating Errors up the Call Stack
Suppose that the readFile method is the fourth method in a series of nested method calls made by
the main program. method1 calls method2, which calls method3 that finally calls readFile.
Suppose also that method1 is the only method interested in the errors that might occur within
readFile.
method1 {
call method2;
}
method2 {
call method3;
}
method3 {
call readFile;
}
Traditional Way of Propagating Errors
Traditional error notification techniques force method2 and method3 to propagate the error codes
returned by readFile up the call stack until the error codes finally reach method1, which is the only
method that is interested in them.
method1 {
errorCodeType error;
error = call method2;
if (error)
doErrorProcessing;
else
proceed;
}
errorCodeType method2 {
errorCodeType error;
error = call method3;
if (error)
return error;
else
proceed;
}
errorCodeType method3 {
errorCodeType error;
error = call readFile;
if (error)
return error;
else
proceed;
}

Using Java Exception Handling
A method can duck any exception thrown within it, thereby allowing a method farther up the call
stack to catch it. Hence, only the methods that care about errors have to worry about detecting
errors.
Any checked exceptions that can be thrown within a method must be specified in its throws clause.
method1 {
try {
call method2;
} catch (Exception ex) {
doErrorProcessing;
}
}
method2 throws Exception {
call method3;
}
method3 throws Exception {
call readFile;
}
Grouping and Differentiating Error Types
‰  Because all exceptions thrown within a program are objects, the grouping or
categorizing of exceptions is a natural outcome of the class hierarchy.
‰  An example of a group of related exception classes in the Java platform are those
defined in java.io IOException and its descendants:
‰  IOException is the most general and represents any type of error that can occur when
performing I/O.
‰  Its descendants represent more specific errors. For example, FileNotFoundException
means that a file could not be located on disk.
‰  A method can write specific handlers that can handle a very specific exception.
‰  The FileNotFoundException class has no descendants, so the following handler can
handle only one type of exception.
catch (FileNotFoundException e) {
...
}
‰  A method can catch an exception based on its group or general type by specifying any
of the super classes of the exception in the catch statement.
‰  For example, to catch all I/O exceptions, regardless of their specific type, an exception
handler specifies an IOException argument.
// Catch all I/O exceptions, including
// FileNotFoundException, EOFException, and so on.
catch (IOException e) {
...
}
Try It Out
Problem Statement:
Write a program that looks for code that invokes a method declaring an exception, where the
calling method does not handle or declare the checked exception.
Code:
import java.io.IOException;
public class ExceptionThrowApp {
void doStuff() {
doMore();
}
void doMore() {
throw new IOException();
}
}
How It Works:
‰  First, the doMore() method throws a checked exception, but does not declare it.
‰  But suppose you fix the doMore() method like the following:
‰  void doMore() throws IOException { … }
‰  The doStuff() method is still in trouble, because it, too, must declare the IOException,
unless it handles it by providing a try or catch, with a catch clause that can take an
IOException.
Tips and Tricks:
When should you use the keyword throws related to exception handling?
Solution:
‰  If you throw an exception in your code, then you must declare it using the throws
keyword in your method declaration.
‰  If you call a method that throws an exception (in other words, a method that declares it
throws an exception), then you must acknowledge that you are aware of the exception
possibility. One way to satisfy the compileris to wrap the call in a try or catch
Summary
‰  Uncaught exceptions propagate back through the call stack, starting from the method
where the exception is thrown and ending with either the first method that has a
corresponding catch for that exception type or a JVM shutdown.
‰  Subtypes of Error or RuntimeException are unchecked, so the compiler does not
enforce the handle or declare rule. You are free to handle them, or to declare them,
but the compiler does not care one way or the other.