Exceptions in Java: Nothing exceptional about them

Exception handling in Java from top to bottom

By Gaurav Pal and Sonal Bansal, JavaWorld.com, 08/18/00

• It separates the working/functional code from the error-handling code by way of try-catch clauses.
• It allows a clean path for error propagation. If the called method encounters a situation it can't manage, it can throw an exception and let the calling method deal with it.
• By enlisting the compiler to ensure that "exceptional" situations are anticipated and accounted for, it enforces powerful coding.

In order to develop a clear and consistent strategy for exception handling, examine these questions that continually plague Java developers:

• Which exceptions should I use?
• When should I use exceptions?
• How do I best use exceptions?
• What are the performance implications?

When trying to design APIs and applications that can cross system boundaries or be implemented by third parties, these issues only exacerbate.

Let's delve deeper into the various aspects of exceptions.

Which exceptions should I use?

Exceptions are of two types:

1. Compiler-enforced exceptions, or checked exceptions
2. Runtime exceptions, or unchecked exceptions

Compiler-enforced (checked) exceptions are instances of the Exception class or one of its subclasses -- excluding the RuntimeException branch. The compiler expects all checked exceptions to be appropriately handled. Checked exceptions must be declared in the throws clause of the method throwing them -- assuming, of course, they're not being caught within that same method. The calling method must take care of these exceptions by either catching or declaring them in its throws clause. Thus, making an exception checked forces the programmer to pay heed to the possibility of it being thrown. An example of a checked exception is java.io.IOException. As the name suggests, it throws whenever an input/output operation is abnormally terminated. Examine the following code:

try
{
   BufferedReader br = new BufferedReader(new FileReader("MyFile.txt"));
   String line = br.readLine();
}
catch(FileNotFoundException fnfe)
{
   System.out.println("File MyFile.txt not found.");
}
catch(IOException ioe)
{
   System.out.println("Unable to read from MyFile.txt");
}

The constructor of FileReader throws a FileNotFoundException -- a subclass of IOException -- if the said file is not found. Otherwise, if the file exists but for some reason the readLine() method can't read from it, FileReader throws an IOException.

Runtime (unchecked) exceptions are instances of the RuntimeException class or one of its subclasses. You need not declare unchecked exceptions in the throws clause of the throwing method. Also, the calling method doesn't have to handle them -- although it may. Unchecked exceptions usually throw only for problems arising in the Java Virtual Machine (VM) environment. As such, programmers should refrain from throwing these, as it is more convenient for the Java VM to manage this part.

Free Download - 5 Minute Product Review. When slow equals Off: Manage the complexity of Web applications - Symphoniq

Free Download - 5 Minute Product Review. Realize the benefits of real user monitoring in less than an hour. - Symphoniq