Browse DevX
Sign up for e-mail newsletters from DevX


Build a Notification Servlet That E-mails Exceptions to App Developers : Page 3

Implement a mechanism that notifies the appropriate developer via e-mail whenever an exception occurs during application testing. With a little bit of effort, you can build a notification servlet that will enable such a mechanism.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

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:


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.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



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