In a typical software development organization, the tasks of development and formal testing are performed by different groups of people. Testing groups commonly encounter application exceptions during their testing processes. All such exceptions typically are recorded as bugs in a bug-tracking system.

Eventually, the bugs make it to the developer whos actually in charge of the source code. Once the developer reads the verbose description of the bug?in the terminology of the tester?the developer sets out to simulate this bug in the development environment. If the developer can accurately reproduce the bug, he or she then obtains a stack trace of the exception and uses it to debug and finally fix the programming error.

This cycle typically spans over days. Wouldn’t it cut down a lot of time and effort if whenever an exception occurred in the application, the appropriate developer for that application was notified with an e-mail and also received a stack trace related to the exception? With a little bit of effort, you can implement a mechanism that does just that.

Build a Notification Servlet
Every application infrastructure has its own exception-handling mechanism. For simplicity, lets consider a class UserDefinedException that extends java.lang.Exception. This class usually customizes exception handling for a particular application. Typically, the UserDefinedException class logs exceptions to a database and provides user-friendly messages, along with exception ids, that a developer can look up in the database to get the complete description of the exception (when it occurred, etc.). Such a UserDefinedException class should be enhanced so that it provides one more feature: sending a HTTP request to a notification servlet!

You might ask: Why a servlet? Why not send notifications from within the UserDefined class? The reason is a servlet would decouple the exception notification mechanism from the actual application, allowing the notification mechanism to be developed/maintained independently. It can be enhanced periodically without impacting regular application development in any way.

The notification servlet is responsible for:

1. Analyzing the exception
2. Deciding which course of action to take depending on the severity of the exception
3. Creating a formatted message that contains the exception or its summary
4. Deciding which output channel to use for sending out the notification, for example e-mail or wireless device
5. Actually sending out the notification

Typically, if the exception’s severity is non-critical, the servlet decides to ignore the exception and not send out any notifications. If the exception is moderately critical, the servlet might send out an e-mail notification, and in case of a severely critical exception, the servlet can send out a notification on a wireless phone.How the Servlet Determines Its Recipients
The most interesting part of this process is how the servlet determines the recipients of its notifications. To explain this process, I propose a very elementary mechanism: a list of developer profiles maintained in a database or other persistent media. Each user profile typically has attributes like the following:

1. Name of developer
2. Information about developer
3. E-mail address of developer
4. Wireless account information of developer
5. Most importantly, a list of Java class names for which the developer is primarily responsible

I can make the UserDefinedException class sensitive to the context in which the exceptions occurred, by capturing the class name of the object wherein the exception occurred. You can see this clearly in the following listing:

public class UserDefinedException extends Exception{    private String mExceptionSourceClassName;    public UserDefinedException(Object sourceObject,Exception e, .....)    {        //capture the exception source's class name        mExceptionSourceClassName = sourceObject.getClass().getName();        //do custom error handling, error logging etc                //send out HTTP request to notification servlet            }}

Usage:

    {        try        {            //some application code        }        catch(Exception e)        {            throw new UserDefinedException(this,e,......)        }    }

Then I can send this Exception Source Class Name across to the notification servlet, which would go through the list of developer profiles to figure out the primary developer for that class name. The servlet would then load the primary developer’s profile and fetch the developer’s e-mail address and wireless account information.

The servlet has access to the generated application exception, its description, and its stack trace, as well as the primary developer’s contact information. Depending on the severity of the exception, the servlet can then send out notifications about the exception, either through e-mail or on a wireless device, using appropriate Java APIs.

The following is a utility class listing, which can e-mail the exception details using SMTP protocol (click here for the notification servlets complete source code):

CE-mailer.java CNotificationServlet.java 

The notification servlet spawns off a thread, CThreadHandleExceptions, which actually handles exception notifications. Utilizing this thread (with the CThreadHandleExceptions.java utility) improves the responsiveness of the notification servlet itself.Notification Overkill
A common complaint with such mechanisms is that they usually generate a large number of notifications, some of them mere repetitions of the same error, which overwhelms the recipients. As a result, many recipients figure out a way of ignoring these notifications, rendering the entire mechanism a futile exercise.

Lets deal with each of these issues one by one.

Too Much Notification?
If every exception in a large-scale application, which a considerable testing team is testing, sent out an e-mail notification, the result could be too many notifications. To overcome this problem, dont send out a notification for each exception but instead decide whether to send out notifications, based on criteria such as the severity of the exception.

For instance, you can easily modify the notification servlet to log all exceptions in a database but send out notifications only for exceptions having VERY_HIGH or HIGH severity.

A more flexible approach would be to let each developer decide the criteria for receiving notifications. For instance, each developer profile can have an attribute called FILTER, which can specify the conditions under which an exception should be sent out as a notification.FILTER can be a hashtable with values like the following:

{"SEVERITY","HIGH,EXTREME""SOURCE_CLASS_NAMES","MyApplication.java,MySecurityModule.java""SOURCE_METHOD_NAMES","OnInitialize,OnReceiveMessageFromBackEnd"}

An incoming exception can be filtered against these user-defined filters to decide whether the exception should result in a notification. Using such filters, a developer can fine-tune the notification mechanism.

Repetitive Notifications
Exceptions that occur in some core modules like infrastructure module commonly cause apparent exceptions in different functionalities of an application. This may result in repetitive exceptions and, therefore, repetitive notifications. Also, developers probably dont want their e-mail inboxes entirely at the whims and fancies of the testing team.

One way to get around this problem is to check for duplicate exceptions. But how do you determine whether an incoming exception is a duplicate and whether a notification for it already has been sent? In this case, each exception has the following key qualifiers:

SOURCE_CLASS_NAME, EXCEPTION_SUMMARY

You can store this combination in a persistent medium the first time the notifications servlet receives the exception. For all subsequent instances, you need to check your persistent medium to see if the incoming exception already has key qualifiers in your persistent log. If yes, the incoming exception is a duplicate and a notification already has been sent.

You also need to provide a mechanism that removes the key qualifiers from persistent media once the bug has been fixed. This can be automated by having the developers acknowledge the e-mail, enabling the notification servlet to poll for e-mails, read them, determining which notifications need to be removed, and finally removing the key qualifiers.

A simpler approach would be to purge the persistent media containing the list of key qualifiers every time a new build goes into testing and the testing team starts off a new cycle.A Notification Servlet Has Many Uses
The notification servlet is command-driven and generic enough to be used for a wide variety of application event notifications (completion/abortion of overnight batch jobs, creation of new application users, certain critical parts of an application being accessed, etc.).

Also, you can easily provide a simple JSP interface to maintain the developer profiles. This same interface can also provide the ability to enable/disable notifications or specify frequency and timing-related rules for sending notifications. Such a custom notification servlet for exception notifications is well worth the effort and definitely will cut down turnaround times for day-to-day bug fixing.