Newsletter sign-up
View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java
Email Address:

Patch an exception-handling framework

Decide at runtime how to handle exceptions

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone

The discussions on exception handling seem endless. Many articles and white papers talk about how to handle exceptions. However, what is missing is an extensible, generic exception-handling framework that provides the user with the ability to decide at runtime how to handle exceptions.

The following problems are generally associated with exceptions and their handlers:

  • Who decides what should be done when an exception occurs in the system? If the developer decides and the client disagrees, what should be done?
  • What details should an exception convey?
  • How can we define exception handling behavior at runtime without modifying the application?

Even if we fix the way an exception should be handled, how do we ensure that the developer actually follows the rule? Being a developer myself, I know it's difficult to follow coding rules. I decided to develop a small exception-handling framework, called Patch, that solves the above problems.

The proposed exception-handling framework provides a completely extensible solution. This framework is developed in Java and is freely available for reuse and further development.

Now let's see how the Patch framework solves each exception problem.

Who decides what should be done when an exception occurs in the system?

This article's exception-handling framework proposes that the client should be able to override the default action performed when an exception occurs, thereby ensuring that, when an exception does occur, the system's behavior suits both the client and the developer. This behavior should be kept outside the main system so that, when the client changes how an exception is handled, the system's main business logic is not affected.

The behavior expected from the exception handler shall hence be defined when the system actually deploys and not during development.

To achieve this behavior, the Patch framework provides a separate set of classes that are used to delegate an exception to the appropriate exception handler. The Patch framework assumes that the following points are always true:

  • The information an exception conveys can be finalized at design time.
  • Every exception handler is expected to handle the exception. The interface between the application and the exception handler can be finalized at design time.

The decision of which exception handler to use is made at runtime using some properties in a configuration file. Taking the above two points into consideration, the Patch framework defines two interfaces:

  • An interface that every exception should implement
  • An interface that every exception handler should implement

The PatchBaseExceptionIntf interface must be implemented by all exceptions that need to be handled by the Patch framework:

 package com.patch.framework.exceptionhandling.model;
   public interface PatchBaseExceptionIntf
   {
      public void setErrorDetails(ErrorDetails errorDetails);
      public ErrorDetails getErrorDetails();
      public String toString();
   }



Note that this interface uses an object type called ErrorDetails, which I will discuss further in the following section.

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone
Comments (1)
Login
Forgot your account info?

how to deal with ErrorDetails classBy Anonymous on March 30, 2009, 2:14 pmHi Your article is very good one i was looking for such. I would like to know how can we deal with the ErrorDetails class. You did not talk about that a lot in...

Reply | Read entire comment

View all comments

Add comment
Anonymous comments subject to approval. Register here for member benefits.
Have a JavaWorld account? Log in here. Register now for a free account.
Resources