Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com

Exceptions to the programming rules, Part 2

Incorporate Java's throw-object/catch-object exception-handling technique into your Java programs

By Jeff Friesen, JavaWorld.com, 04/05/02

  • Print
  • Feedback
.

Page 6 of 8

'throws' exceptionIdentifier1 ',' exceptionIdentifier2 ',' ...


The throws clause begins with keyword throws and continues with a comma-delimited list of exceptionIdentifier's. Each exceptionIdentifier identifies the class of a checked exception object directly (or indirectly, through a called method) thrown from the method. The following code fragment illustrates a throws clause: 

public static void main (String [] args) throws java.net.MalformedURLException
{
   if (args.length < 1) return;
   java.net.URL url = new java.net.URL (args [0]);
}


The above code fragment attempts to create an object from Java's URL class -- found in package java.net. If the contents of the String object, which args [0] references, do not represent a valid URL, the URL (String url) constructor throws a java.net.MalformedURLException object. Because that object represents a checked exception and because the main() method chooses not to receive that object, a throws clause must append to main()'s signature -- to inform the JVM that main() did not receive that object and that the JVM should begin searching for an appropriate exception handler with main()'s caller. (I explore URLs in a future article.)

Tip
To deal with failure that occurs inside a constructor, throw an exception object from that constructor. If the exception object is checked, append a throws clause to the constructor signature. For example: class Employee { Employee () throws IOException { /* ... appropriate code ... */ } }. When a constructor throws an exception object, the JVM does not create an object from the constructor's class. Using the previous example, if Employee() throws an IOException object, the JVM does not create an Employee object.


Throws clauses and method overriding

In "Object-Oriented Language Basics, Part 4," you learned about method overriding. In that article, you learned you must exactly specify a superclass method's name, return type, and parameter list in a subclass when overriding the superclass method. Because a throws clause is part of a method's signature, when overriding a superclass method that has a throws clause, keep in mind two factors:

  • When an exception class name appears in a subclass method's throws clause, either that name must also appear in the superclass method's throws clause or the name of the exception class's superclass must appear in the superclass method's throws clause.
  • An unchecked exception class name that appears in a subclass method's throws clause need not appear in the superclass method's throws clause. The compiler ignores unchecked exception class names when examining throws clauses.


To understand throws clauses and method overriding, consider the following code fragment: 

import java.io.*;
class Parent
{
   void foo () throws IOException
   {
   }
}
class Child extends Parent
{
   void foo () throws EOFException, ArrayIndexOutOfBoundsException,
                      ClassNotFoundException
   {
   }
}


According to the code fragment, Child overrides Parent's foo() method. Notice both classes' throws clauses. Parent's throws clause lists one exception class (IOException), whereas Child's clause lists three: java.io.EOFException, ArrayIndexOutOfBoundsException, and java.lang.ClassNotFoundException.

Why won't the code fragment compile? Might the problem involve ArrayIndexOutOfBoundsException? The answer is no: the compiler ignores ArrayIndexOutOfBoundsException and other unchecked exception class names. Might the problem involve EOFException? Once again, the answer is no: class EOFException subclasses IOException, and you can legally list an exception subclass name in a subclass method's throws clause, provided the exception subclass's superclass name appears in the superclass method's throws clause. The problem lies with ClassNotFoundException; that checked exception class name does not appear in Parent's throws clause, and IOException is not ClassNotFoundException's superclass.

Catch exception objects

After the JVM acquires an exception object from either the JVM or a program/library, the JVM searches program/library code for a handler capable of dealing with those exceptions that the exception object's type represents. The search results in either a suitable program/library exception handler or the JVM's default exception handler. The JVM subsequently transfers the exception object and its execution to that exception handler. The acts of locating, calling, and passing the exception object to the exception handler are collectively known as catching an exception object.

The exception handler typically calls various exception object methods to learn more about the exception. Method return values assist the exception handler in its job -- although the default exception handler only displays those values so you can find out what went wrong and fix your code. See the earlier SortIntegerArray1 output for an example of what the default exception handler displays.

To represent an exception handler in source code, Java uses the catch clause. That clause has the following syntax:

  • Print
  • Feedback

Resources