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
.

Page 2 of 5

java.lang.ArithmeticException is an example of an unchecked exception thrown when an exceptional arithmetic condition has occurred. For example, an integer "divide by zero" throws an instance of this class. The following code illustrates how to use an unchecked exception: 

public static float fussyDivide(float dividend, float divisor) throws 
FussyDivideException
{
   float q;
   try
   {
    q = dividend/divisor;
   }
   catch(ArithmeticException ae)
   {
      throw new FussyDivideException("Can't divide by zero.");
   }
}
public class FussyDivideException extends Exception
{
   public FussyDivideException(String s)
   {
      super(s);
   }
}


fussyDivide() forces the calling method to ensure that it does not attempt to divide by zero. It does this by catching ArithmeticException -- an unchecked exception -- and then throwing FussyDivideException -- a checked exception.

To help you decide whether to make an exception checked or unchecked, follow this general guideline: If the exception signifies a situation that the calling method must deal with, then the exception should be checked, otherwise it may be unchecked.

When should I use exceptions?

The Java Language Specification states that "an exception will be thrown when semantic constraints are violated," which basically implies that an exception throws in situations that are ordinarily not possible or in the event of a gross violation of acceptable behavior. (See Resources for the The Java Language Specification, written by James Gosling, Bill Joy, and Guy Steele.)

In order to get a clearer understanding of the kinds of behavior that can be classified as "normal" or exceptional, take a look at some code examples.

Case 1

Passenger getPassenger()
{
   try
   {
      Passenger flier = object.searchPassengerFlightRecord("Jane Doe");
   catch(NoPassengerFoundException npfe)
   {
      //do something
   }
}


Case 2

Passenger getPassenger()
{
   Passenger flier = object.searchPassengerFlightRecord("Jane Doe");
      if(flier == null)
         //do something
}


In Case 1, if the search for the passenger is not fruitful, then the NoPassengerFoundException throws; whereas in Case 2, a simple null check does the trick. Developers encounter situations similar to the preceding in their day-to-day work; the trick is to engineer a sound and efficient strategy.

So, following the general philosophy behind exceptions, should you dismiss the possibility that searches will return nothing? When a search comes up empty, is it not more a case of normal processing? Therefore, in order to use exceptions judiciously, choose the approach in Case 2 over Case 1. (Yes -- We recognize the performance angle. If this code were in a tight loop, then multiple if evals would adversely affect performance. However, whether or not the if statement lies in the critical path would be known only after profiling and extensive performance analysis. Empirical results show that trying to code for performance up front -- ignoring sound design principles -- tends to produce more harm than good. So, go ahead and design the system right in the first cut, and then change later if you must.)

  • Print
  • Feedback

Resources