An Exception Handling Framework for J2EE Applications

Wrap third-party exceptions into application-specific exceptions

Whenever an exception originates from other external interfaces (components), it should be wrapped in an application-specific exception and handled accordingly.

Example:

try {

    BeanUtils.copyProperties(areaDTO, areaForm);

} catch (Exception se) {

    throw new CopyPropertiesException(

        "Exception occurred while using 

            copy properties", se);

}

Here, CopyPropertiesException extends java.lang.RuntimeException, as we would just like to log it. We are catching Exception instead of catching the specific checked exceptions that the copyProperties method could throw, since for all of those exceptions we're throwing the same unchecked CopyPropertiesException.

Too Many Exceptions

You may be wondering, if we create an exception for each error message, could we run into in an overflow of exception classes themselves? For instance, if "Order not found" were an error message for OrderNotFoundException, you certainly wouldn't like to have CustomerNotFoundException for an error message "Customer not found" for an obvious reason: the two exceptions represent the same thing, and differ only in the contexts in which they are used. So if we could specify the context while handling the exception, we could certainly reduce these exceptions to just one RecordNotFoundException. Here is an example:

try{

    ...

}catch(BaseAppException ex){

    IExceptionHandler eh =ExceptionHandlerFactory

      .getInstance().create();

    ExceptionDTO exDto = eh.handleException(

        "employee.addEmployee", userId, ex);

}

Here, the employee.addEmployee context will be appended to the error code of a context-sensitive exception, to make a unique resultant error code. For instance, if the error code for RecordNotFoundException is errorcode.recordnotfound, the resultant error code for this context will become errorcode.recordnotfound.employee.addEmployee, which will be a unique error code for this context.

However, there is a caveat: if you are using multiple interfaces in the same client method and they all could throw RecordNotFoundException, it would be really difficult to know for which entity you got this exception. In cases where business interfaces are public and can be used by various external clients, it's recommended to use specific exceptions only and not a generic exception like RecordNotFoundException. Context-specific exceptions are really useful for DB-based recoverable exceptions where exception classes are always the same and the difference comes only in the contexts in which they occur.

Exception Hierarchy for a J2EE Application

As discussed earlier, we need to define a base exception class, say BaseAppException, that contains the default behavior of all application exceptions. We'll just put this base class in throws clause of every method that potentially throws a checked exception. All checked exceptions for an application should be the subclasses of this base class. There are various ways of defining error-handling abstractions. However, these differences should have more to do with business cases and not technical compulsions. The abstraction of error-handling can be divided into the following categories. All of these exceptions classes will derive from BaseAppException.