Sams Teach Yourself Visual J++ 6 in 21 Days
(Publisher: Macmillan Computer Publishing)
Author(s): Rick Leinecker
ISBN: 0672313510
Publication Date: 11/01/98

Java Exceptions

Java features a general-purpose error-processing system known as an exception mechanism. The exception mechanism is composed of two parts: throwing exceptions and catching them. To throw an exception means to signal an error, whereas to catch one is to trap and handle an error that was previously thrown. Exceptions provide a uniform approach to signaling and processing errors, removing much of the burden of traditional error processing.

The term exception is short for exceptional event. Exceptional events are those that disrupt the normal flow of program execution. C++ programmers will find Java’s exception mechanism very similar to that of C++ and will be throwing and catching exceptions in no time. If you’re a C programmer, you’ll find learning to use Java’s exception mechanism well worth the effort.

In languages other than Java, such as C, each function is responsible for signaling success or failure during execution. In many cases, this is done by returning an integer value that the caller can test. Generally, if the return value of a function is zero, the function is executed without error. If a nonzero value is resumed, an error might have occurred during execution.

However, not all routines return error codes, and those that do return them don’t necessarily report errors in the same way. Some might return an error code, others might return a null value, and still others might set a global error variable. Such inconsistencies place a substantial burden on the programmer, who must learn the error-reporting mechanism employed by each routine and write the appropriate code to test for errors.

As a result, many programmers save time by testing only for errors generated by critical routines, not bothering with the others. In some cases, the programmer might not fully understand the routine in question and might handle errors incorrectly. In both cases, the integrity of the program suffers and error checking becomes a nuisance, if not a nightmare.

Using exceptions, Java provides developers with a consistent and relatively simple mechanism for signaling and dealing with errors. Exceptions provide methods with a way to stop program execution when an error is encountered, while allowing the method to notify its caller that a problem has occurred. If the caller chooses, it can ignore, or “duck,” the exception, in which case the exception is passed down the call stack until it is dealt with. However, exceptions allow you only to temporarily pass the buck when an error is encountered, because you must deal with the error eventually.

Managing the Call Stack

A call stack is nothing more than the sequence of methods that have been invoked. For instance, if a method named drawShape() calls another method named drawCircle(), you have a pretty simple call stack. Here, you can see that drawShape() calls the drawCircle() method. The drawShape() method is said to be at the “bottom” of the stack, and drawCircle() is at the “top.”

However, drawCircle() might invoke another method named draw(). This would then sit at the top of the call stack. And draw() might call another method, named paint(), as the call stack continued to grow. If an exception occurred in paint(), it could possibly be ignored by every method. As a result, the exception would be passed all the way down the call stack.

If an exception isn’t handled by a method, it’s passed down the call stack to the method below it. If none of the methods in the call stack catches the exception by the time it reaches the bottom, and the method at the bottom doesn’t catch it either, the program is aborted!

Somewhere along the way, the exception will have to be caught and dealt with. If it isn’t, the program will be aborted. If you try to write a Java program without catching an exception, the compiler warns you.

---

Caution:  In Java, all nonruntime exceptions must be caught or declared. If they are not, the compiler spits out an error message. If the compiler realizes that a nonruntime error hasn’t been properly handled, it refuses to compile the code. When this is the case, you must either catch or declare the exception.

---