A typical error handling practice is to wrap a piece of suspect code in a "try" block, and present a warm and fuzzy message in the "catch" block. But, after a user has seen that warm and fuzzy message a few dozen times, it becomes cold and pointy (opposite of fuzzy?). This is defensive error handling. An error happens, so you put up a message defending your site, and sometimes even blame the user!
There are more offensive approaches that can be taken, all of which assist in permanently fixing the issue or condition which caused the error in the first place. These methods allow us to provide a better customer-oriented message when an error does occur, such as "error message, but we have been notified of the issue and will be working to resolve it as soon as possible."
When I use the term error, I'm referring to the true meaning of the word – a logical or other unexpected runtime issue in your program. Whereas, exceptions refer to expected situations, such as File Not Found. We can't prevent exceptions from occurring, but our program should be 100% error free.
Site error email notifications
Of course, you're wondering why on earth you would want to be emailed whenever an error occurs on your website, when you have error logs that serve the same purpose, but in a far less intrusive manner.
For me, the intrusive manner in which those errors are emailed to me places a sense of urgency on resolving the error. Not to mention your motivation to fix the error so you don't keep getting emails! WIth the sites that I employ this method, they are 99.9% error free. Once in a great while do I get an error email, typically generated by a search engine visiting a page that expects certain parameters.
Plus, doing a monthly check on the error logs would be overwhelming. Instead of fixing dozens of errors at once, why not fix them as they happen?
ColdFusion
You are able to specify a global error handler in Application.cfc. I personally like to include as much error and client detail as possible, so I know exactly what circumstance caused the error. My typical Application.cfc err hander looks like this:
<cffunction name="onError" returnType="void" output="true">
<cfargument name="Exception" required="true">
<cfargument name="EventName" type="string" required="true">
<cfsavecontent variable="mail_html">
Redirect URL: <cfoutput>#CGI.REDIRECT_URL#</cfoutput><br />
ARGUMENTS.EXCEPTION:
<cfdump var="#Arguments.Exception#">
CGI:
<cfdump var="#CGI#">
ARGUMENTS.EVENTNAME
<cfdump var="#Arguments.EventName#">
FORM SCOPE:
<cfdump var="#form#">
URL SCOPE:
<cfdump var="#url#">
</cfsavecontent>
<cfmail to="errors@mydomain.com" from="webmaster@mydomain.com" type="html"
subject = "Website Error - #CGI.REDIRECT_URL# - #Arguments.Exception.Message#">
#mail_html#
</cfmail>
</cffunction>
PHP
The PHP documentation website does a pretty good job of describing the PHP global error handler, so I won't pretend to know more than they do! Consider dropping some email code within your error handler, and include the arguments provided to the error handler within the email.
JavaScript
I touched on this in a previous post, Fun with JavaScript Strings and Prototype, although, I would not recommend implementing it in that fashion. Instead, create a separate logging "class" to house this function.
In a nutshell, the post discusses the possibility of using AJAX to log JavaScript errors and messages to your server.
Tracking Error Frequency over Time
Most application servers do a good job of logging errors to a text file, which provides a chronological listing of runtime errors that occurred since you last emptied the log file or restarted the server. While this is useful, it doesn't help us determine if our offensive error handling efforts are paying off.
To get a clearer picture, it makes sense to store errors in a database table. I'd suggest adding a single table to your site's database:
CREATE TABLE error_log (
error_log_id INTEGER AUTO_INCREMENT,
error_log_type VARCHAR(64),
error_log_message VARCHAR(256),
error_log_client_ip VARCHAR(32),
error_log_url VARCHAR(256),
error_log_created DATETIME,
PRIMARY KEY (error_log_id)
);
Then, within your global error handler, add a record the error_log table with the error details. This approach will make the process of creating a basic error tracking tool much more relaxed.
Let the bots do it
The approach I discussed above essentially uses your website visitors as test dummies, letting them ferret out the errors in your code. This might be okay if they get that "warm and fuzzy" error message we talked about earlier. But, it goes without saying, that your visitor would much rather relevant content than an error message of any kind. So, how can we simulate visitors? The bad guys do it in the form of spam bots, submitting forms pretending to be a user for any number of reasons. But, there are good guys too. This site lists a few good testing tools that you might find useful to simulate a visitor (although they typically do a better job of simulating how a search engine sees your site):