Uncaught Exceptions

Before you learn how to handle exceptions in your program, it is useful to see what happens
when you don’t handle them. This small program includes an expression that intentionally
causes a divide-by-zero error:
class Exc0 {
public static void main(String args[]) {
int d = 0;
int a = 42 / d;
}
}
When the Java run-time system detects the attempt to divide by zero, it constructs a
new exception object and then throws this exception. This causes the execution of Exc0 to
stop, because once an exception has been thrown, it must be caught by an exception handler
and dealt with immediately. In this example, we haven’t supplied any exception handlers of
our own, so the exception is caught by the default handler provided by the Java run-time
system. Any exception that is not caught by your program will ultimately be processed by
the default handler. The default handler displays a string describing the exception, prints a
stack trace from the point at which the exception occurred, and terminates the program.
Here is the exception generated when this example is executed:
java.lang.ArithmeticException: / by zero
at Exc0.main(Exc0.java:4)
Notice how the class name, Exc0; the method name, main; the filename, Exc0.java;
and the line number, 4, are all included in the simple stack trace. Also, notice that the type
of exception thrown is a subclass of Exception called ArithmeticException, which more
specifically describes what type of error happened. As discussed later in this chapter, Java
supplies several built-in exception types that match the various sorts of run-time errors that
can be generated.
The stack trace will always show the sequence of method invocations that led up to
the error. For example, here is another version of the preceding program that introduces the
same error but in a method separate from main( ):
class Exc1 {
static void subroutine() {
int d = 0;
int a = 10 / d;
}
public static void main(String args[]) {
Exc1.subroutine();
}
}
The resulting stack trace from the default exception handler shows how the entire call
stack is displayed:
java.lang.ArithmeticException: / by zero
at Exc1.subroutine(Exc1.java:4)
at Exc1.main(Exc1.java:7)
As you can see, the bottom of the stack is main’s line 7, which is the call to subroutine( ),
which caused the exception at line 4. The call stack is quite useful for debugging, because it
pinpoints the precise sequence of steps that led to the error.