Exceptions - Beginning Java - page 370

throw new DreadfulProblemException("Terrible difficulties");
In all the examples of throwing your own exception, the stack trace record inherited from the superclass
Throwable is set up automatically.
If you plan to use your exception type in a catch block to provide further information about an exception
that has been thrown, you can make provision for recording the original exception:
try {
// Code that may throw SomeException...
} catch SomeException e) {
// Analyze the cause...
throw new DreadfulProblemException("Disaster strikes!", e);
}
This fragment throws an object of your exception class that you create with a constructor that accepts a
second argument of type Throwable to record the previous exception object. This will enable the code that
catches your exception to access the SomeException object that caused your exception to be thrown and
extract information from that.
An Exception Handling Strategy
You should think through what you want to achieve with the exception handling code in your program.
There are no hard-and-fast rules. In some situations you may be able to correct a problem and enable your
program to continue as though nothing happened. In other situations, outputting the stack trace and a fast
exit is the best approach — a fast exit being achieved by calling the exit() method in the System class.
Here you take a look at some of the things you need to weigh when deciding how to handle exceptions.
Consider the last example where you handled arithmetic and index-out-of-bounds exceptions in the di-
vide() method. Although this was a reasonable demonstration of the way the various blocks worked, it
wasn't a satisfactory way of dealing with the exceptions in the program for at least two reasons.
• First, it does not make sense to catch the arithmetic exceptions in the divide() method without
passing them on to the calling method. After all, it is the calling method that set the data up, and
only the calling program has the potential to recover the situation.
• Second, by handling the exceptions completely in the divide() method, you allow the calling
program to continue execution without any knowledge of the problem that arose. In a real situation
this would undoubtedly create chaos, as further calculations would proceed with erroneous data.
You could have simply ignored the exceptions in the divide() method by having no try - catch combin-
ation for the exception. This might not be a bad approach in this particular situation, but the first problem the
calling program would have is determining the source of the exception. After all, such exceptions might also
arise in the calling program itself. A second consideration could arise if the divide() method were more
complicated. There could be several places where such exceptions might be thrown, and the calling method
would have a hard time distinguishing them.
An Example of an Exception Class
Another possibility is to catch the exceptions in the method where they originate and then pass them on to
the calling program. You can pass them on by throwing new exceptions that provide more granularity in