ch3.htm

JAVA Developing Professional JavaApplets

reacts by calling <TT>mouseDown()</TT>.
If this is overridden by the object in question, its version of
the method will be called. Like <TT>handleEvent()</TT>,
the return value of the helper methods indicate whether the event
has been completely handled.
<P>
Table 3.2 lists the available Event helper methods, which are
all part of the definition of the Component class.<BR>
<P>
<CENTER><B>Table 3.2. Event helper methods.</B></CENTER>
<P><CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR VALIGN=TOP><TD WIDTH=134><I>Method</I></TD><TD WIDTH=325><I>Description</I>
</TD></TR>
<TR VALIGN=TOP><TD WIDTH=134><TT>mouseEnter</TT>
</TD><TD WIDTH=325>Mouse enters the Component's area</TD></TR>
<TR VALIGN=TOP><TD WIDTH=134><TT>mouseExit</TT>
</TD><TD WIDTH=325>Mouse leaves the Component's area</TD></TR>
<TR VALIGN=TOP><TD WIDTH=134><TT>mouseMove</TT>
</TD><TD WIDTH=325>Mouse has moved</TD></TR>
<TR VALIGN=TOP><TD WIDTH=134><TT>mouseDown</TT>
</TD><TD WIDTH=325>Mouse has been pressed down</TD></TR>
<TR VALIGN=TOP><TD WIDTH=134><TT>mouseDrag</TT>
</TD><TD WIDTH=325>Mouse has moved while it is pressed down</TD>
</TR>
<TR VALIGN=TOP><TD WIDTH=134><TT>mouseUp</TT>
</TD><TD WIDTH=325>Mouse click has been released</TD></TR>
<TR VALIGN=TOP><TD WIDTH=134><TT>keyDown</TT>
</TD><TD WIDTH=325>Keyboard character has been pressed</TD></TR>
<TR VALIGN=TOP><TD WIDTH=134><TT>keyUp</TT></TD>
<TD WIDTH=325>Keyboard character has been released</TD></TR>
<TR VALIGN=TOP><TD WIDTH=134><TT>action</TT>
</TD><TD WIDTH=325>An action has occurred to the Component</TD>
</TR>
<TR VALIGN=TOP><TD WIDTH=134><TT>gotFocus</TT>
</TD><TD WIDTH=325>The input focus has been placed on the Component
</TD></TR>
<TR VALIGN=TOP><TD WIDTH=134><TT>lostFocus</TT>
</TD><TD WIDTH=325>The Component has lost input focus</TD></TR>
</TABLE></CENTER>
<H2><A NAME="ExceptionClasses"><FONT SIZE=5 COLOR=#FF0000>Exception
Classes</FONT></A></H2>
<P>
Although the basics of exception handling were discussed in the
first part of the book, there is a lot more to managing exceptions
in Java than just the &quot;try-catch&quot; clause. The class
of exceptions that is thrown and what information can be gleaned
from the thrown object are also important topics. This part of
exception handling is related to Java's exception class hierarchy,
the subject of this section.
<H3><A NAME="TheThrowableClass">The Throwable Class</A></H3>
<P>
All throwable objects in Java are an instance of, or are subclassed
from, the Throwable class, which encapsulates the behaviors found
in all the throwable classes that are part of the Java API. One
widely used method of Throwable is <TT>getMethod()</TT>.
This prints out a detail message attached to the thrown object.
The detail message will give extra information regarding the nature
of the error. If the default constructor of the thrown object
is used, a system-generated detail message will be provided. If
you want a custom message, on the other hand, an alternative constructor
can be used.
<P>
A couple of examples will illustrate using detail messages. Suppose
an operation is performed that results in an error. The following
code will catch the thrown object and print out the detail message:
<BLOCKQUOTE>
<TT>try {<BR>
&nbsp;&nbsp;// &#133; do something that causes an exception, such
as <BR>
divide by zero<BR>
}<BR>
catch (Throwable t) {<BR>
&nbsp;&nbsp;// Print out the detail message of the error&#133;
<BR>
&nbsp;&nbsp;System.out.println(t.getMessage());<BR>
}</TT>
</BLOCKQUOTE>
<P>
In another case, suppose that the same code wants to rethrow the
message with its own custom detail message if there is an error.
The other constructor for Throwable can be used in this situation
to construct the custom message:
<BLOCKQUOTE>
<TT>try {<BR>
&nbsp;&nbsp;// &#133; do something that causes an exception, such
as <BR>
divide by zero<BR>
}<BR>
catch (Throwable t) {<BR>
&nbsp;&nbsp;// Throw a new Throwable object with<BR>
&nbsp;&nbsp;// Custom detail message&#133;<BR>
&nbsp;&nbsp;throw new Throwable(&quot;This method threw an <BR>
exception&quot;);<BR>
}</TT>
</BLOCKQUOTE>
<P>
When the new Throwable is caught and <TT>getMessage()</TT>
is invoked, the program will get the String <TT>&quot;This
method threw an exception&quot;</TT> instead of a system-generated
message.
<P>
Other methods in Throwable can be used for getting the state of
the runtime stack when the error occurred. The <TT>printStackTrace()</TT>
method, for example, prints to standard error the kind of stack
output that you often see when a Java program terminates abnormally.
<H3><A NAME="ExceptionClassHierarchy">Exception Class Hierarchy</A>
</H3>
<P>
All the other exception classes in the Java API behave similarly
to the Throwable class. They differ only in how they are located
in the hierarchy of class exceptions. Java divides errors into
two general groupings, indicated by two parent classes derived
from Throwable. The Exception class represents the kind of errors
that occur in a normal programming environment, such as file not
found, array index out of bounds, null pointers, divide by zero,
and so forth. These are &quot;soft&quot; errors, the type of difficulty
that a program should be able to easily recover from. In general,
Exception classes represent errors that are meant to be caught
by the calling method whenever they occur. Classes derived from
the Error class, on the other hand, represent more serious errors
that can occur at unpredictable times and are often fatal in nature.
An extreme case of such an Error is a failure within the Java
virtual machine. If this occurs, often the best you can hope for
is an orderly shutdown of the program. Because of their unpredictable
and catastrophic nature, Error objects do not have to be caught
in exception handlers. In general, programs will be written to
catch only classes derived from the Exception class.<BR>
<P><CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR VALIGN=TOP><TD><B>Note</B></TD></TR>
<TR VALIGN=TOP><TD>
<BLOCKQUOTE>
From a terminological standpoint, &quot;exception&quot; (lowercase) is used to refer to all classes of thrown objects. The term &quot;error&quot; (lowercase also) refers to the circumstances that cause the object to be thrown.</BLOCKQUOTE>

</TD></TR>
</TABLE></CENTER>
<P>
<P>
As mentioned in the first part of this book, a method establishes
that it throws an Exception that has to be caught in its declaration.
For example, this is the constructor for the class that opens
a file for output:
<BLOCKQUOTE>
<TT>public FileOutputStream(String name)
throws IOException</TT>
</BLOCKQUOTE>
<P>
This declaration means that an instance of IOException is thrown
whenever the file specified in the String cannot be opened. The
IOException class is derived from Exception, so any code that
uses this FileOutputStream constructor must catch this exception.
This means that code using this constructor must be generally
structured as follows:
<BLOCKQUOTE>
<TT>try {<BR>
&nbsp;FileOutputStream fo = new FileOutputStream(&quot;MyFile&quot;);
<BR>
&nbsp;// &#133; write the file&#133;<BR>
{<BR>
catch (IOException e) {<BR>
&nbsp;&nbsp;// &#133;Handle the file open problem&#133;<BR>
}</TT>
</BLOCKQUOTE>
<P>
With one notable exception, all methods that throw objects of
type Exception must be called in an exception handler that catches
the Exception. However, Java provides a branch of Exceptions of
thrown objects that do not have to be caught. These are derived
from the RuntimeException class. Subclasses of the RuntimeException
class are those problems that would be too cumbersome to trap
every time they may occur. For example, all accesses to arrays
could result in an exception because the index into the array
could be bad. However, it would be unwieldy to put an exception
handler around all array calls. There would also be a performance
hit. Even worse are instances of the NullPointerException class
being thrown, which theoretically could occur anywhere in the
program.
<P>
Just because an exception is a subclass of RuntimeException, however,
doesn't mean that a good program should not trap for the thrown
object. For example, the ArithmeticException usually indicates
a divide by zero error. It is good programming to trap for this
error whenever it occurs. In most cases, division doesn't often
occur in a program. Consequently, a clause like the following
is appropriate for many division operations:
<BLOCKQUOTE>
<TT>try {<BR>
&nbsp;result = divider / divisor;<BR>
}<BR>
catch (ArithmeticException e) {<BR>
&nbsp;System.out.println(&quot;Divide by zero error!&quot;);<BR>
&nbsp;result = 0;<BR>
}</TT>
</BLOCKQUOTE>
<P>
On the other hand, it is acceptable to have a divide operation
that is not part of an exception handler, since ArithmeticException
is a subclass of RuntimeException. Here is a list of the subclasses
of RuntimeException:<BR>

<P><CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR VALIGN=TOP><TD WIDTH=481><I>The Subclasses of RuntimeException</I></TD>
</TR>
<TR VALIGN=TOP><TD WIDTH=481>
<BLOCKQUOTE>
ArithmeticException<BR>
ArrayIndexOutOfBoundsException<BR>
ArrayStoreException<BR>
ClassCastException<BR>
IllegalArgumentException<BR>
IllegalMonitorStateException<BR>
IllegalThreadStateException<BR>
IndexOutOfBoundsException<BR>
NegativeArraySizeException</BLOCKQUOTE>

</TD></TR>
</TABLE></CENTER>
<P>
<H3><A NAME="ExceptionHandlersandThrowableClasses">Exception Handlers
and Throwable Classes</A></H3>
<P>
The Exception class hierarchy serves a more fundamental purpose
in Java programming than just providing a way to order exception
classes; it plays an important role in determining how an exception
is handled. When an exception is thrown, Java looks for an exception
handler to catch the thrown object. It first looks in the method
where the error occurred, checking to see whether it has an appropriate
exception handler-one that is the class or a superclass of the
exception thrown. Recall that an exception handler can have multiple
catch statements. The catch statements should be ordered in such
a way that a subclass is listed before any of its superclasses.
Here is a possible exception handler for managing a variety of
problems:
<BLOCKQUOTE>
<TT>try {<BR>
&nbsp;// &#133; some bad arithmetic operation<BR>
&nbsp;// &#133; or maybe a bad array access<BR>
&nbsp;// &#133; or a null errror</TT>
</BLOCKQUOTE>
<BLOCKQUOTE>
<TT>}<BR>
catch (ArithmeticException e) {<BR>
&nbsp;// Handle the exception&#133;<BR>
</TT>
</BLOCKQUOTE>
<BLOCKQUOTE>
<TT>}<BR>
catch (RuntimeException e) {<BR>
&nbsp;// Handle the runtime exception&#133;<BR>
}</TT>
</BLOCKQUOTE>
<BLOCKQUOTE>
<TT>catch (Exception e) {<BR>
&nbsp;// Handle the Exception&#133;<BR>
}<BR>
catch (Throwable e) {<BR>
&nbsp;// Handle the thrown object&#133;<BR>
}</TT>
</BLOCKQUOTE>
<P>
Recall that ArithmeticException is a subclass of RuntimeException.
The latter is derived from Exception, which in turn is a subclass
of Throwable. In this example, a divide by zero error throws an
ArithmeticException, which is handled in the first catch statement.
On the other hand, a NullPointerException or a bad array access
will result in a RuntimeException object being thrown, which is
handled in the second catch statement. A serious problem of class
Error will not be handled until it reaches the last catch statement,
which will catch the thrown object since Error is a subclass of
Throwable. This example illustrates that the exception class hierarchy
is a critical part of Java's strategy for resolving exceptions.
<P>
If the method that caused an object to be thrown does not have
an appropriate exception handler, the object percolates up the
call stack, and this process of finding an appropriate handler
is repeated. If it reaches the top of the stack and no appropriate
handler is found, the program will terminate abnormally.
<H3><A NAME="WritingCustomExceptionHandlers">Writing Custom Exception
Handlers</A></H3>
<P>
It's easy to write your own exception handler. A class is simply
created that extends the class that should function as the superclass.
If a new IOException handler is needed, for example, it could
be written as the following:
<BLOCKQUOTE>
<TT>public class CustomIOException extends
IOException { }</TT>
</BLOCKQUOTE>
<P>
The hard part, however, is deciding what the superclass of the
handler should be. In general, it should not be a subclass of
Error since these are reserved for &quot;hard&quot; system problems.
Using RuntimeException should also be discouraged because of an
interesting controversy over whether there should even be such
a thing as a RuntimeException class. This is because, in some
ways, the use of RuntimeException classes defeats some of the
goals of exception handling. By definition, a RuntimeException
object does not have to be caught, but this would then increase
the likelihood of an exception not being caught at all, forcing
the program to terminate abnormally. This defeats a key goal of
exception handling, which is to have a graceful resolution of
problems. Thus, the use of RuntimeException is reserved for classes
of errors that would occur too frequently to have an exception
handler every time the pertinent methods are called.
<P>
This leaves the subclasses of Exception as the best candidate
for being the superclass of new exception classes. Some good examples
can be found in the organization of the exceptions in the Java
IO package. One of the c