Nobody likes errors, but the bottom line is, they're a fact of programming life. The better you are at pinpointing them, the better your code will get. Unfortunately, ColdFusion has never provided very good functionality for tracking the errors that occur within your production applications. I mean how many of you actually look through your application.log? For those of us with busy servers and busy schedules, that becomes an impossibility...

Thus good tools are needed. ColdFusion 4 and 5 and MX include a Log Files reporting tool in the CF Administrator. For some, that still may not be enough. It would be helpful, for instance, to extract the log of errors into a database for subsequent reporting. Right off the bat, it seems Allaire/Macromedia didn't fully think things through as the application.log is not easily parsed.

The problem is, when certain types of errors occur (such as ODBC errors), quotes appear within the text of the error and that interferes with the quotes used as field delimiters for the log. Rather than give up on our goal, however, we can find an alternative solution. What if we could handle errors ourselves rather than rely solely on after-the-fact log analysis?

Enter ColdFusion's error handling. Since version 4.5, Macromedia has made available improved error handling. One of the early restrictions CF developers faced was not being able to run any ColdFusion code on an error-handling page. It was the old chicken and egg problem - what happens if an error occurs on the error-handling page? Fortunately we don't have to worry about those kinds of restrictions anymore.

There are several ways of dealing with errors by executing ColdFusion tags, such as CFTRY/CFCATCH, the CFERROR tag (using TYPE=Exception), and the site-wide error handler that can be enabled through the CF Administrator. These have been discussed in various previous CFDJ articles, such as Charlie Arehart's four-part series starting in October 2000 at www.sys-con.com/coldfusion/article.cfm?id=165.

In this article, we'll take advantage of the site-wide error handler, which will catch any errors that fall through the cracks and interrupt a page from running.

There are a couple of things to be aware of about error handling, such as with the site-wide handler. First, when using it to intercept an error, CF will not write the error to the application.log. You'll have to do that yourself if you really want to (see Listing 1).

Listing 1: Writing out to application.log
<cflog text="#error.diagnostics#" log="APPLICATION"
type="Error" thread="yes" date="yes"
time="yes" application="yes">

Since our end result was to parse the application.log and insert that into a database, we'll skip the step of writing out the log and insert each error directly into the database as it occurs.

Listing 2 contains the database tables that we'll use for our application. Note the "fixID" field at the end of the "errorLog" table. We'll set that as we correct our errors so that we know which ones have been fixed.

Listing 2: Table and index creation
CREATE TABLE errorLog (
logID int IDENTITY (1,1) NOT NULL,
application varchar(20) NULL,
errorDetail varchar(2200) NULL,
errorBase64 varchar(3000) NULL,
errorStamp datetime NOT NULL,
errorType varchar(30) NULL,
browser varchar(100) NULL,
remoteAddr varchar(15) NULL,
httpReferer varchar(255) NULL,
server varchar(30) NULL,
template varchar(255) NULL,
scriptName varchar(200) NULL,
queryString varchar(120) NULL,
fixID smallint NULL
)

PRIMARY KEY: logID
INDEXES: fixID, errorDetail, errorBase64, errorType, application, template

CREATE TABLE errorFixes (
fixID int IDENTITY (1,1) NOT NULL,
logID int NULL,
fixDetail varchar(500) NULL,
fixStamp datetime NULL
)

PRIMARY KEY: fixID
INDEXES: logID

Listing 3 contains the CF code for your site-wide error handler that will insert the error into the database. There are several error types that are common to ColdFusion and might be present in your application (see Table 1). We'll later produce a report that groups things by these types, so we'll add some code right before the insert query to determine the type of error that has occurred. Feel free to add additional code to catch specific errors that you want grouped into the "Other" category.

Listing 3: Inserting the error via SQL
<Cflock scope="application" type="readonly" timeout="10">
<Cfset variables.appName = #application.applicationName#>
</cflock>

<cfif Left(trim(error.diagnostics),4) is 'ODBC' or
Left(trim(error.diagnostics),5) is 'OLEDB' or
Left(trim(error.diagnostics),30)
is 'Error Executing Database Query'>
<cfset errorType = "Database Error">
<cfelseif Left(trim(error.diagnostics),17) is 'Request timed out'>
<cfset errorType = "Request Timeout">
<cfelseif error.diagnostics contains 'Error resolving parameter'>
<cfset errorType = "Error Resolving Parameter">
<cfelseif error.diagnostics contains 'Error resolving parameter <B>SESSION.'>
<cfset errorType = "Session Timeout">
<cfelseif Left(trim(error.diagnostics),53) is
'<P>An error occurred while evaluating the expression:'>
<cfset errorType = "Error Evaluating Expression">
<cfelseif Left(trim(error.diagnostics),30) is 'Just in time compilation error'>
<cfset errorType = "Compilation Error">
<cfelse>
<cfset errorType = "Other Error">
</cfif>

<cfquery name="InsertLogRecord" datasource="#request.datasource#">
INSERT INTO errorLog (errorStamp, errorDetail, errorBase64, errorType, template,
queryString, browser, remoteAddr, httpReferer, application, server, scriptName) VALUES
(#CreateODBCDateTime(error.DateTime)#, '#left(trim(error.diagnostics),2200)#',
'#Trim(Left(ToBase64(error.diagnostics),3000))#', '#errorType#', '#error.template#',
'#error.queryString#','#error.browser#', '#error.RemoteAddress#',
'#ERROR.HTTPReferer#', '#variables.appName#', '#cgi.server_name#', '#cgi.script_name#')
</cfquery>

Note that you could add more to this logging of information, such as writing out session identifiers (CFID, CFTOKEN, and/or JSessionID if using J2EE sessions in CFMX). Also, the locking of access to the application.applicationname variable is something that could be removed if this code is run in CFMX.

Of course, this listing is just a fragment of what you could do in the error handler. For more information on site-wide error handlers, including how to create one, how to provide notification to the user about the error, and optionally how to send e-mail notification to someone in your shop about the error, see the second part in the previously mentioned series, "Toward Better Error Handling - Part 2: Site Wide Error Handling" from December 2000, at www.sys-con.com/coldfusion/article.cfm?id=181.

You may notice that I chose to create a column called errorBase64. Let me explain, and you may need to make some adjustments based upon your database. Specifically, if your database cannot handle sub-selects (as we'll explain later and see in Listing 5), we cannot do comparisons directly within the database given the approach we'll be using. Therefore we'll need a way to encode special characters such as quotes. Most enterprise databases such as Oracle and MS SQL will have no problems with sub-selects, and MS Access supports them as well, but some databases such as mySQL do not (although support is coming soon).

Fortunately, there is an easy workaround. You can add one additional field to your database table to store the error encoded in Base64 (we've reflected this in the code listings). Those of you who store binary files directly in your databases may already be familiar with the ToBase64() function which does just that. If your database does handle sub-selects, you can ignore all references to Base64 as you won't need to do any conversions.

Now that we're collecting all of our errors, we need a way to make sense of it all.

So what's next? Well, we need a way to sort and organize our errors so that we can start to see which are our biggest problems. In our completed application, we've created a CFC called error.cfc with a number of CFFUNCTION methods that are used to search the database we've created. There are several ways you may want to sort including by template, by application, newest first, most frequent, and by type of error. Later we'll look at some different ways to sort and view your errors. For now, we'll just list the newest errors first (see Listing 4). Notice that we added the "WHERE fixID IS NULL" line to our query in order to not include errors that have already been corrected.

Listing 4: Newest errors
<cffunction name="byNewest" displayName="Newest Errors"
access="public" returnType="query" output="false">
<cfset var getErrors = "">
<cfquery name="getErrors" datasource="#request.datasource#">
SELECT logID, application, errorDetail, errorStamp FROM errorLog
WHERE fixID IS NULL
ORDER BY errorStamp DESC
</cfquery>
<cfreturn getErrors>
</cffunction>

We might then call that CFC using code such as:

<cfinvoke component="errors" method="byNewest"
returnvariable="GetErrors"></cfinvoke>
<cfoutput query="getErrors">#application# : #errorDetail# :
#errorStamp#<br></cfoutput>

The code in Listing 5 will display an individual error. You should set up a separate page to drill down to this info. The GetSimilar query will show you how many times the specific error you're viewing appears in the log. You'll need to comment out either the "with sub-selects" or "without sub-selects" portion of the code depending upon your database's capabilities. We then add one column to the end of our original query listing the "SimCount," or the number of times a matching error appears.

Listing 5: Get detail
<cffunction name="getDetail" displayName="Get Error Detail"
access="public" returnType="query" output="false">
<cfargument name="logID" type="numeric" required="true">
<cfset var getError = "">
<cfset var getSimilar = "">
<cfset var simCount = arrayNew(1)>
<cfquery name="getError" datasource="#request.datasource#">
SELECT * FROM errorLog WHERE logID = #ARGUMENTS.logID#
</cfquery>
<!--- with sub-selects --->
<cfquery name="GetSimilar" datasource="#request.datasource#">
SELECT count(*) as numSimilar FROM errorLog
WHERE errorDetail = (SELECT errorDetail FROM errorLog
WHERE logID = #ARGUMENTS.logID#)
AND logID != #ARGUMENTS.logID#
</cfquery>

<!--- without sub-selects --->
<cfquery name="GetSimilar" datasource="#request.datasource#">
SELECT count(*) as numSimilar FROM errorLog
WHERE errorBase64 = '#getError.errorBase64#'
AND logID != #ARGUMENTS.logID#
</cfquery>

<!--- create an array and add column to query --->
<cfset simCount[1] = GetSimilar.numSimilar>
<cfset QueryAddColumn(getError, "SimCount", simCount)>
<cfreturn getError>
</cffunction>

To keep our error log manageable, we need a way to mark errors as corrected once the code has been fixed. At the bottom of the screen displaying an individual error, we'll add a textarea field for entering the fix we performed. When we submit a fix, we'll mark the error as solved (see Listing 6) and also update all of the matching errors since those should now be corrected also (note the slight query changes depending on whether your database can handle sub-selects).

Listing 6: Enter problem fix
<cffunction name="enterFix" displayName="Enter Problem Fix"
access="public" returnType="void" output="false">
<cfargument name="logID" type="numeric" required="true">
<cfargument name="errorFix" type="string" required="true">
<cfset var enterFix = "">
<cfset var getMatching = "">
<cfset var getBase64 = "">
<cfset var getMatching = "">
<cfset var updateLogTable = "">
<cfquery name="enterFix" datasource="#request.datasource#">
INSERT INTO errorFixes (logID, fixDetail, fixStamp)
VALUES (#ARGUMENTS.logID#, '#ARGUMENTS.errorFix#',
#CreateODBCDateTime(Now())#)
</cfquery>

<!--- with sub-selects --->
<cfquery name="GetMatching" datasource="#request.datasource#">
SELECT logID FROM errorLog WHERE errorDetail =
(SELECT errorDetail FROM errorLog WHERE logID = #ARGUMENTS.logID#)
</cfquery>

<!--- without sub-selects --->
<cfquery name="GetBase64" datasource="#request.datasource#">
SELECT errorBase64 FROM errorLog WHERE logID = #ARGUMENTS.logID#
</cfquery>
<cfquery name="GetMatching" datasource="#request.datasource#">
SELECT logID FROM errorLog WHERE errorBase64 =
'#GetBase64.errorBase64#'
</cfquery>

<cfquery name="updateLogTable" datasource="#request.datasource#">
UPDATE errorLog SET fixID = #enterFix.id# WHERE logID IN
(#ValueList(getMatching.logID)#)
</cfquery>
</cffunction>

We now have a way to list, view, and fix the latest errors that occur. Next we'll look at various other ways of sorting and viewing our data. Previously we only listed the newest errors first - now we'll sort by application, template, top errors, and error types (see Listings 7-10). These views will allow you to see which errors are occurring the most based upon your selection criteria. The errCount alias in each query will keep track of the number of errors for that grouping and the maxStamp alias will hold the last date that an error for that grouping has occurred.

Listing 7: Errors by application
<cffunction name="byApplication" displayName="Errors By Application"
access="public" returnType="query" output="false">
<cfset var getErrors = "">
<cfquery name="getErrors" datasource="#request.datasource#">
SELECT application, count(logID) as errCount,
max(errorStamp) as maxStamp FROM errorLog
WHERE fixID IS NULL
GROUP BY application
ORDER BY errCount DESC
</cfquery>
<cfreturn getErrors>
</cffunction>

This could be called with:

<cfinvoke component="errors" method="byApplication"
returnvariable="GetErrors"></cfinvoke>
<cfoutput query="getErrors">#application# : #errCount# :
#maxStamp#<br></cfoutput>

Listing 8: Errors by template
<cffunction name="byTemplate" displayName="Errors By Template"
access="public" returnType="query" output="false">
<cfset var getErrors = "">
<cfquery name="getErrors" datasource="#request.datasource#">
SELECT template, application, count(*) as errCount,
max(errorStamp) as maxStamp FROM errorLog
WHERE fixID IS NULL
GROUP BY template, application
ORDER BY errCount DESC
</cfquery>
<cfreturn getErrors>
</cffunction>

This could be called with:

<cfinvoke component="errors" method="byTemplate"
returnvariable="GetErrors"></cfinvoke>
<cfoutput query="getErrors">#template# : #application# : #errCount# :
#maxStamp#<br></cfoutput>

Listing 9: Top errors
<cffunction name="byTopErrors" displayName="Top Errors" access="public"
returnType="query" output="false">
<cfset var getErrors = "">
<cfquery name="getErrors" datasource="#request.datasource#">
SELECT errorDetail, application, count(logID) as errCount,
max(errorStamp) as maxStamp, max(logID)as maxLogID
FROM errorLog
WHERE fixID IS NULL
GROUP BY errorDetail, application
ORDER BY errCount DESC
</cfquery>
<cfreturn getErrors>
</cffunction>

This could be called with:

<cfinvoke component="errors" method="byTopErrors"
returnvariable="GetErrors"></cfinvoke>
<cfoutput query="getErrors"> #application# : #errorDetail# : #errCount# :
#maxStamp#<br></cfoutput>

Listing 10: Errors by error type
<cffunction name="byErrorType" displayName="Errors By Error Type"
access="public" returnType="query" output="false">
<cfset var getErrors = "">
<cfquery name="getErrors" datasource="#request.datasource#">
SELECT errorType, count(*) as errCount, max(errorStamp) as maxStamp
FROM errorLog
WHERE fixID IS NULL
GROUP BY errorType
ORDER BY errCount DESC
</cfquery>
<cfreturn getErrors>
</cffunction>

This could be called with:

<cfinvoke component="errors" method="byErrorType"
returnvariable="GetErrors"></cfinvoke>
<cfoutput query="getErrors"> #errorType# : #errCount# :
#maxStamp#<br></cfoutput>

Used effectively, this tool will speed your application performance and improve your coding style. Good luck!