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 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

  • Print
  • Feedback
.
Java projects rarely feature a consistent and thorough exception-handling strategy. Often, developers add the mechanism as an afterthought or an as-you-go addition. Significant reengineering during the coding stage can make this oversight an expensive proposition indeed. A clear and detailed error- and exception-handling strategy pays off in the form of robust code, which in turn, enhances user value. Java's exception-handling mechanism offers the following benefits:

  • 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.

  • Print
  • Feedback

Resources