The Three Kinds of Exceptions
The first kind of exception is the checked exception. These are exceptional conditions that a well-written application should anticipate and recover from. For example, suppose an application prompts a user for an input file name, then opens the file by passing the name to the constructor for java.io.FileReader. Normally, the user provides the name of an existing, readable file, so the construction of the FileReader object succeeds, and the execution of the application proceeds normally. But sometimes the user supplies the name of a nonexistent file, and the constructor throws java.io.FileNotFoundException. A well-written program will catch this exception and notify the user of the mistake, possibly prompting for a corrected file name.
Checked exceptions are subject to the Catch or Specify Requirement. All exceptions are checked exceptions, except for those indicated by Error, RuntimeException, and their subclasses.
The second kind of exception is the error. These are exceptional conditions that are external to the application, and that the application usually cannot anticipate or recover from. For example, suppose that an application successfully opens a file for input, but is unable to read the file because of a hardware or system malfunction. The unsuccessful read will throw java.io.IOError. An application might choose to catch this exception, in order to notify the user of the problem — but it also might make sense for the program to print a stack trace and exit.
Errors are not subject to the Catch or Specify Requirement. Errors are those exceptions indicated by Error and its subclasses.
The third kind of exception is the runtime exception. These are exceptional conditions that are internal to the application, and that the application usually cannot anticipate or recover from. These usually indicate programming bugs, such as logic errors or improper use of an API. For example, consider the application described previously that passes a file name to the constructor for FileReader. If a logic error causes a null to be passed to the constructor, the constructor will throw NullPointerException. The application can catch this exception, but it probably makes more sense to eliminate the bug that caused the exception to occur.
Runtime exceptions are not subject to the Catch or Specify Requirement. Runtime exceptions are those indicated by RuntimeException and its subclasses.
Errors and runtime exceptions are collectively known as unchecked exceptions
Java's Unchecked RuntimeException Subclasses
Exception Meaning
ArithmeticException Arithmetic error, such as divide-by-zero.
ArrayIndexOutOfBoundsException Array index is out-of-bounds.
ArrayStoreException Assignment to an array element of an incompatible type.
ClassCastException Invalid cast.
IllegalArgumentException Illegal argument used to invoke a method.
IllegalMonitorStateException Illegal monitor operation, such as waiting on an unlocked thread.
IllegalStateException Environment or application is in incorrect state.
IllegalThreadStateException Requested operation not compatible with current thread state.
IndexOutOfBoundsException Some type of index is out-of-bounds.
NegativeArraySizeException Array created with a negative size.
NullPointerException Invalid use of a null reference.
NumberFormatException Invalid conversion of a string to a numeric format.
SecurityException Attempt to violate security.
StringIndexOutOfBounds Attempt to index outside the bounds of a string.
TypeNotPresentException Type not found. (Added by J2SE 5.)
UnsupportedOperationException An unsupported operation was encountered.
Java's Checked Exceptions Defined in java.lang
Exception Meaning
ClassNotFoundException Class not found.
CloneNotSupportedException Attempt to clone an object that does not implement the Cloneable interface.
IllegalAccessException Access to a class is denied.
InstantiationException Attempt to create an object of an abstract class or interface.
InterruptedException One thread has been interrupted by another thread.
NoSuchFieldException A requested field does not exist.
NoSuchMethodException A requested method does not exist.
Throwing an Exception from a Method
- Most of the time a try block is accompanied by a catch block that catches the java.lang.Exception in addition to other catch blocks.
- The order of the catch blocks is important.
- The more specific exception type appears first.
public class MainClass {
public static void main(String[] args) {
String input = null;
try {
String capitalized = capitalize(input);
System.out.println(capitalized);
}
catch (NullPointerException e) {
System.out.println(e.toString());
}
}
public static String capitalize(String s) throws NullPointerException {
if (s == null)
{
throw new NullPointerException("Your passed a null argument");
}
Character firstChar = s.charAt(0);
String theRest = s.substring(1);
return firstChar.toString().toUpperCase() + theRest;
}
}
The try Block
The first step in constructing an exception handler is to enclose the code that might throw an exception within a try block. In general, a try block looks like the following.
try {
code
}
catch and finally blocks . . .
try {
System.out.println("Entered try statement");
out = new PrintWriter(new FileWriter("OutFile.txt"));
for (int i = 0; i < SIZE; i++) {
out.println("Value at: " + i + " = "
+ vector.elementAt(i));
}
The catch Blocks
You associate exception handlers with a try block by providing one or more catch blocks directly after the try block. No code can be between the end of the try block and the beginning of the first catch block.
try {
} catch (ExceptionType name) {
} catch (ExceptionType name) {
}
Each catch block is an exception handler and handles the type of exception indicated by its argument. The argument type, ExceptionType, declares the type of exception that the handler can handle and must be the name of a class that inherits from the Throwable class. The handler can refer to the exception with name.
The catch block contains code that is executed if and when the exception handler is invoked. The runtime system invokes the exception handler when the handler is the first one in the call stack whose ExceptionType matches the type of the exception thrown. The system considers it a match if the thrown object can legally be assigned to the exception handler's argument.
try {
} catch (FileNotFoundException e) {
System.err.println("FileNotFoundException: " + e.getMessage());
throw new SampleException(e);
} catch (IOException e) {
System.err.println("Caught IOException: " + e.getMessage());
}
Both handlers print an error message. The second handler does nothing else. By catching any IOException that's not caught by the first handler, it allows the program to continue executing
The finally Block
The finally block always executes when the try block exits. This ensures that the finally block is executed even if an unexpected exception occurs. But finally is useful for more than just exception handling — it allows the programmer to avoid having cleanup code accidentally bypassed by a return, continue, or break. Putting cleanup code in a finally block is always a good practice, even when no exceptions are anticipated.
finally {
if (out != null) {
System.out.println("Closing PrintWriter");
out.close();
} else {
System.out.println("PrintWriter not open");
}
}
public void writeList() {
PrintWriter out = null;
try {
System.out.println("Entering try statement");
out = new PrintWriter(
new FileWriter("OutFile.txt"));
for (int i = 0; i < SIZE; i++)
out.println("Value at: " + i + " = "
+ vector.elementAt(i));
} catch (ArrayIndexOutOfBoundsException e) {
System.err.println("Caught "
+ "ArrayIndexOutOfBoundsException: "
+ e.getMessage());
} catch (IOException e) {
System.err.println("Caught IOException: "
+ e.getMessage());
} finally {
if (out != null) {
System.out.println("Closing PrintWriter");
out.close();
}
else {
System.out.println("PrintWriter not open");
}
}
}
Chained Exceptions
An application often responds to an exception by throwing another exception. In effect, the first exception causes the second exception. It can be very helpful to know when one exception causes another. Chained Exceptions help the programmer do this.
The following are the methods and constructors in Throwable that support chained exceptions.
Throwable getCause()
Throwable initCause(Throwable)
Throwable(String, Throwable)
Throwable(Throwable)
The Throwable argument to initCause and the Throwable constructors is the exception that caused the current exception. getCause returns the exception that caused the current exception, and initCause sets the current exception's cause.
The following example shows how to use a chained exception.
try {
} catch (IOException e) {
throw new SampleException("Other IOException", e);
}
Unchecked Exceptions — The Controversy
Because the Java programming language does not require methods to catch or to specify unchecked exceptions (RuntimeException, Error, and their subclasses), programmers may be tempted to write code that throws only unchecked exceptions or to make all their exception subclasses inherit from RuntimeException. Both of these shortcuts allow programmers to write code without bothering with compiler errors and without bothering to specify or to catch any exceptions. Although this may seem convenient to the programmer, it sidesteps the intent of the catch or specify requirement and can cause problems for others using your classes.
Why did the designers decide to force a method to specify all uncaught checked exceptions that can be thrown within its scope? Any Exception that can be thrown by a method is part of the method's public programming interface. Those who call a method must know about the exceptions that a method can throw so that they can decide what to do about them. These exceptions are as much a part of that method's programming interface as its parameters and return value.
The next question might be: "If it's so good to document a method's API, including the exceptions it can throw, why not specify runtime exceptions too?" Runtime exceptions represent problems that are the result of a programming problem, and as such, the API client code cannot reasonably be expected to recover from them or to handle them in any way. Such problems include arithmetic exceptions, such as dividing by zero; pointer exceptions, such as trying to access an object through a null reference; and indexing exceptions, such as attempting to access an array element through an index that is too large or too small.
Runtime exceptions can occur anywhere in a program, and in a typical one they can be very numerous. Having to add runtime exceptions in every method declaration would reduce a program's clarity. Thus, the compiler does not require that you catch or specify runtime exceptions (although you can).
One case where it is common practice to throw a RuntimeException is when the user calls a method incorrectly. For example, a method can check if one of its arguments is incorrectly null. If an argument is null, the method might throw a NullPointerException, which is an unchecked exception.
Generally speaking, do not throw a RuntimeException or create a subclass of RuntimeException simply because you don't want to be bothered with specifying the exceptions your methods can throw.
Write a catch block that handles java.lang.Exception
All Java exception classes derive from the java.lang.Exception class. When a method throws multiple exceptions, rather than catch all the exceptions, you can simply write a catch block that handles java.lang.Exception
public class MainClass {
public static void main(String[] args) {
String input = null;
try {
String capitalized = capitalize(input);
System.out.println(capitalized);
} catch (Exception e) {
System.out.println(e.toString());
}
}
static String capitalize(String s) throws NullPointerException, AlreadyCapitalizedException {
if (s == null) {
throw new NullPointerException("Your passed a null argument");
}
Character firstChar = s.charAt(0);
if (Character.isUpperCase(firstChar)) {
throw new AlreadyCapitalizedException();
}
String theRest = s.substring(1);
return firstChar.toString().toUpperCase() + theRest;
}
}
class AlreadyCapitalizedException extends Exception {
public String toString() {
return "Input has already been capitalized";
}
}
Handling Exceptions
public class MainClass {
public static void main(String[] args) {
int i = 1;
int j = 0;
try {
System.out.println("Try block entered " + "i = " + i + "j = " + j);
System.out.println(i / j); // Divide by 0 - exception thrown
System.out.println("Ending try block");
} catch (ArithmeticException e) { // Catch the exception
System.out.println("Arithmetic exception caught");
}
System.out.println("After try block");
return;
}
}
Multiple catch Blocks
public class MainClass {
public static void main(String[] args) {
int[] x = { 10, 5, 0 };
try {
System.out.println("First try block in main() entered");
divide(x, 0);
x[1] = 0;
divide(x, 0);
x[1] = 1;
divide(x, 1);
} catch (ArithmeticException e) {
System.out.println("Arithmetic exception caught in main()");
} catch (ArrayIndexOutOfBoundsException e) {
System.out.println("Index-out-of-bounds exception caught in main()");
}
}
private static void divide(int[] intArray, int j) {
for (int i : intArray) {
System.out.println(i);
System.out.println(j);
System.out.println(i / j);
System.out.println();
}
}
}
The finally Block
import java.io.IOException;
public class MainClass {
public static void main(String[] args) {
try {
System.out.println("In second try block in main()");
System.in.read();
return;
} catch (IOException e) {
System.out.println("I/O exception caught in main()");
} finally {
System.out.println("finally block for second try block in main()");
}
System.out.println("Code after second try block in main()");
}
}
Defining Your Own Exceptions, Throwing Your Own Exception
class DreadfulProblemException extends ArithmeticException {
public DreadfulProblemException() {
}
public DreadfulProblemException(String s) {
super(s);
}
}
public class MainClass{
public static void main(String[] a){
int[] array = new int[]{1,0,2};
int index = 0;
try {
System.out.println("First try block in divide() entered");
array[index + 2] = array[index]/array[index + 1];
System.out.println("Code at end of first try block in divide()");
} catch(ArithmeticException e) {
System.out.println("Arithmetic exception caught in divide()");
throw new DreadfulProblemException("index + 1"); // Throw new exception
} catch(ArrayIndexOutOfBoundsException e) {
System.out.println(
"Index-out-of-bounds index exception caught in divide()");
}
System.out.println("Executing code after try block in divide()");
}
}
