Storing Error Information

One difference between an in-house application and a commercial application is the response of the development team when errors in the application are found. In an in-house application, errors are typically noted and scheduled to be fixed in a release or two. If developers cannot find a workaround and the error is critical, they must fix it immediately. In a commercial application, this is not the case. The best that can happen is that the error is reported and you, as the user, hope that it eventually gets fixed because you do not have any control over a commercial application. If it is a problem that affects your business, you cannot really count on a quick fix.

Another difference is how the errors get logged. In a commercial application, there is no real log for errors that occur and no real way to track those errors. The development team of a commercial application must rely on the users correctly reporting errors. If the user tells you that an error occurred but cannot give you the circumstances in which it occurred, finding it is going to be difficult. An in-house application, on the other hand, has a number of advantages in this area. The application is run on a network you control and connected to a database you control. You can also write error handling routines that will benefit the entire enterprise.

SEI-CMM

The Carnegie Mellon University in conjunction with the U.S. government developed the Software Engineering Institute Capability Maturity Model (SEI-CMM). The purpose of this institute, and the SEI-CMM specifically, was to create a disciplined approach to software development. One of the main tenets in the CMM is the process of capturing metrics for quality assurance. These metrics range from code development estimates to the number of bugs found and the number of bugs fixed. It also covers many other metrics—too many to mention here.

Many organizations are now switching to the SEI-CMM model because it is a proven method for reducing costs and improving quality. Because tracking bugs is crucial to gathering metrics, this chapter becomes an integral part of any enterprise software development.

To learn more about the SEI-CMM, visit the Carnegie Mellon Web site at http://www.sei.cmu.edu/cmm/cmm.sum.html.

To track bugs, you will store the application errors in a database table. Storing errors in a database table allows the development team to keep accurate metrics on the errors generated by the application. It also allows the development team to find and fix errors faster than having to rely on a user reading the error information to a technical support person. And, using this method gives the development team the chance to be notified that a user had an error at the same time that the error occurred. How many enterprise applications do you know of that have this capability built in?

However, other types of errors can occur that will prevent application errors from being logged. These errors can range from network errors to server errors to database errors. What do you do then? You use the Windows Event Log. This log stores application and system information—including errors. But in VB 6 developers could not take a lot of advantage of it unless they used the Win32 Application Programming Interface (API), which was troublesome at times. The .NET Framework provides the System.Diagnostic namespace for dealing with the Windows Event Log.

The next section discusses the specific classes in the System.Diagnostic namespace. Now that you have had a brief introduction to handling errors in the enterprise, it is time to start writing your own custom, generic error handler. The first step is to set up your database.