March 3, 2021
Hot Topics:

Handling Anomalies: Errors and Exceptions

  • By Matt Weisfeld
  • Send Email »
  • More Articles »

Anomaly Handling

It is rare for a class to be written perfectly the first time. In most, if not all, situations, things will go wrong. Any designer who does not plan for problems is courting danger.

Assuming that your code has the ability to detect and trap an anomalous condition, you can handle the anomaly in several different ways: In the book Java Primer Plus, the authors state that there are three basic solutions to handling a problem that is detected in a program: "fix it, ignore the problem by squelching it, or exit the runtime in some graceful manner".

A variation on this theme is presented in the book Object-Oriented Design in Java. The authors expand on this theme by adding the choice of throwing an exception. The options are:

  • Ignore the problem—not a good idea!
  • Check for potential problems and abort the program when you find a problem.
  • Check for potential problems, catch the mistake, and attempt to fix the problem.
  • Throw an exception. (Often, this is the preferred way to handle the situation.)

Let me talk about each of these strategies.

Ignoring the Problem

Simply ignoring a potential problem is a recipe for disaster. To illustrate, consider the situation where you purposely generate an anomaly. In this case, you do a simple divide by zero that will untimely crash the application, as seen in Listing 1.

// Class ErrorHandling
public class ErrorHandling {

   public static void main(String[] args) {

      int a = 0;
      int b = 0;
      int c = 0;

      c = a / b;    // divide by zero

      System.out.println("At the end ");



Listing 1: Generating an Error—Ignoring the exception

Understanding the flow of control in these applications is important. As you see in Diagram 2, the application's flow of control is interrupted by the operating system when the divide by zero is encountered.

Click here for a larger image.

Diagram 2: An Object with two References and two Objects (different content)

At this point, the application loses control of the process and is aborted. Control returns to the operating system. You can see this by observing the output in Figure 1.

Click here for a larger image.

Figure 1: Generating an Error—Ignoring the problem

This scenario is not a happy ending for the user. How many times have you been using a software application when the application crashed? Although this used to be a more common occurrence several years ago, it is still an unwelcome situation. And, when a situation such as this does occur, the results can be anywhere from annoying to devastating. When an application has an uncontrolled abort, there is a distinct possibility that data will be lost or corrupted. One of the cardinal rules pertaining to software applications is that an application should avoid an uncontrolled abort (crash) at all costs. If an application continuously crashes, users are very likely to stop using (buying) the product.

If you do make the effort to detect the problem, you might as well figure out how to handle it; if you are going to ignore the problem, why bother detecting it in the first place? The bottom line is that you should not ignore the problem. If you do not handle your errors, the application will eventually terminate ungracefully or continue in a mode that can be considered an unstable (unsafe) state. In the latter case, you might not even know you are getting incorrect results for some period of time—and this can be dangerous.

Page 2 of 5

This article was originally published on August 6, 2007

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date