Application Error Trapping

August 27th, 2008

Before one line of code is written a proactive strategy for identifying, categorizing and reporting application errors needs to be developed.  Certainly, there are multiple logs, such as the server, database and even language logs, that can be examined to get some idea of what is not functioning properly on the site.  However, this is mostly a reactive approach.  A better way to handle the proactive and immediate identification of many errors is to incorporate error trapping and reporting functionality right from the start of the project.

The first place to start is with the database.  Database systems are designed and built with extremely good error trapping.  However, most developers and applications do not take advantage of this functionality, either because they are unaware of the richness and value of the information when there is a problem, but more likely it is initially easier and faster to bypass the inclusion of application code to adequately handle the errors.  Nonetheless, some type of database error will occur, ranging from an out of expected range parameter, to multiple returned rows when only one is expected, to no rows returned when one is expected or to a deadlock.  Knowing the database error, and possibly the specific parameters, at the time of execution saves time and effort in both tracking down the issue and developing a solution to prevent it from happening again.

The next place to incorporate error trapping is at the individual application page level.  Errors such as missing, unexpected or out of range global, session or page level variables need to be identified and reported.  Again, the idea is to be able to quickly and proactively identify problems and improve the ability to diagnose and correct any issues.

Whenever an error occurs, it is not the expected user experience.  In many cases, the end-user sees a long, extremely tech specific message on the screen and is pretty much left confused and, in many cases, annoyed.  Therefore, it is important to attempt to present the end-user with some type of nicely designed and worded message and/or page acknowledging the error and informing them that someone will be looking at the error to try to prevent it from happening in the future.

Once you’ve come up with a means by which you can adequately handle page level errors you must then develop a scheme for reporting the errors to the appropriate person within the organization for further investigation and resolution.  You should also store the error so that you have enough information to review the errors and perform analysis in the future.  The easiest way to perform these tasks is to have the application send an email message to the appropriate person regarding the error and then to process and store some of the basic information in an error database.

Again, it takes much less effort and time to incorporate error trapping into the application as it is being built than it does to have to go back and retrofit it.  It also makes the identification and resolution of the inevitable issues that come up much easier and faster to resolve, resulting in a better experience for your site visitors.

One area I didn’t talk about in this post was site monitoring which I will leave for another day.

Comments are closed.