Java Reference
In-Depth Information
It includes the location where the exception occurred. The second line in the output indicates
that the exception has occurred inside the main() method of the com.jdojo.exception.
DivideByZero class. The source code is contained in the DivideByZero.java file. The line
number in the source code that caused the exception is 7.
You may notice that in just two lines of output the Java runtime has printed enough pieces of information to help
you track down the error in your code.
When z = x/y at line 7 is executed, the Java runtime detects the exceptional condition, which is an attempt
to divide an integer by zero. It creates a new object of the class ArithmeticException with all relevant pieces of
information about the exception, and then throws (or passes) this object to an exception handler. Who caught
(or handled) the exception in this case? You did not specify any exception handler in the code. In fact, you do not
even know how to specify an exception handler at this point. Because you did not specify an exception handler in this
case, the Java runtime handled the exception for you. Does the Java runtime handle all exceptions that are thrown in
a Java program? The answer is yes. The Java runtime handles all exceptions in a Java program. However, It handles an
exception only when you do not handle it yourself.
If an exception occurs and the Java runtime does not find a programmer-defined exception handler to handle it,
such an exception is called an uncaught exception . All uncaught exceptions are handled by the Java runtime. Because
an uncaught exception is always handled by the Java runtime, why should you even worry about providing any
exception handler in your program? This is an interesting point. Why do you need to worry about doing something
that would be done by the Java runtime for you? If you are too lazy to clean up your own mess (handling your own
error condition), there is bad news for you. You should not expect too much from the Java runtime. You may not
like the way the runtime handles exceptions for you. It catches the uncaught exception, prints the error stack on the
standard error, and halts your Java application. In other words, if you let the Java runtime handle all your exceptions,
your program stops executing at the point where the exception occurs. Is this what you want to do? The answer would
be no. Sometimes, after you handle the exception, you may want to proceed with executing the rest of your program
rather than halting the program. When you ran the DivideByZero class, the expression x/y in the statement z = x/y
resulted in an exception. Java did not finish executing the statement z=x/y . Sometimes this situation is phrased as
“The statement z=x/y finished abnormally.” The runtime handled the exception, but it stopped executing the whole
program. This is the reason that you do not see the output of the following statement in your program:
System.out.println("z = " + z);
Now you know that letting the runtime handle your exception is not always a good idea. If you want to handle
exceptions yourself, you need to place your code in a try block. A try block looks like the following:
try {
// Code for the try block goes here
}
A try block starts with the keyword try , followed by an opening brace and a closing brace. The code for the try
block is placed inside the opening and the closing braces.
A try block cannot be used just by itself. It must be followed by one or more catch blocks, or one finally block, or a
combination of both. To handle an exception that might be thrown by the code inside a try block, you need to use a catch
block. One catch block can be used to handle multiple types of exceptions. For now, I'll focus on handling only one type of
exception in a catch block; I'll cover how to handle multiple exceptions in a catch block in a separate section.
The syntax for a catch block is similar to the syntax for a method.
catch (ExceptionClassName parameterName) {
// Exception handling code goes here
}
Search WWH ::




Custom Search