This article explains the process of implementing error handling for a fix red page on hacked site utilizes server-side scripting. Proper error handling is necessary to ensure that users of a website have a good experience during their visit. Any professional website should be thoroughly tested on a staging server before being deployed on the live web server. However, it is not always possible to anticipate every possible error and good error handling will notify both the user and the webmaster about problems with the website in a production environment.
When we talk about website errors, there are two different types we need to talk about. Fatal errors cause execution of the script to halt and a page error (HTTP status code 501) to be reported to the user. An exception is an error thrown by server-side script that may be captured through scripting and allow the web page to still be displayed. An example of this kind of exception is a database query which causes an exception but doesn't abort execution of the current script.
Building a Code Library
In order to provide consistent error handling throughout a website, a shared code module should be created which provides the majority of the error handling details. The goal here is not to repeat code so that everything is handled in one central location. That way, any changes or modifications that need to be made to the code only have to be done once. A good error handling library will contain methods for displaying a friendly message to the visitor and also collect all of the debugging information needed for technical support.
Every programming language is different, so it will be up to the developer to decide how to best implement the error handling. The goal should be to make it flexible and intuitive so that it can be used in many different scenarios. It should only require a minimal amount of code to wrap a section of scripting code with error handling.
Displaying Friendly Messages
There are various options for displaying friendly error messages to the user. One option is to just stop processing of the entire page and display an error that reads "Sorry, this web page cannot be displayed at this time due to an internal issue. Our technical support team has been notified and will work quickly to resolve this issue." This is often the best way to handle any unexpected errors that we can handle through server-side scripting.
Another option is to display as much of the page as possible and place a highly visible error message on the screen. This message would read "Unable to perform action due to an internal error." The point of this type of handling is that we give the user the opportunity to correct the issue and attempt the action again. This type of situation is typically a from submission where bad data causes an error in the web page.
Debug Information
When the server-side code can handle the error, it is important that debug information is sent to the webmaster and technical support team so that issues can be resolved quickly. This debug information is very different from the friendly error message which is displayed to the user. It contains very detailed information about the code which caused the error, and any other pertinent information.
One of the most common errors is a database error due to a malformed SQL statement for websites which do not use stored procedures. This type of error can easily be caught and handled through server-side code. In this case, the type of debug information we would like to see is the source of the error (file name and line number) with a stack trace and the offending SQL script which caused the error.
Some other bits of information we would like to see is the URL including the query string. The request method (GET or POST) and all form variables passed to the script. Additionally, any cookies set on the client's machine would also be beneficial for reproducing the error. This sounds like a lot and it is. The point is, we need to get as much information as possible so that the issue can be identified and corrected quickly.
Transmitting Debug Information
Once we have this debug information, we need to transmit it to the webmaster and tech support team. The easiest way of doing this is to send an e-mail containing all of the above information. Another method is to store this information in a database where it is accessible through a company intranet.
As a best practice, you should consider doing both to eliminate the possibility that one method fails. Of course, if the whole script fails and stops executing, then no information will be sent out. This is one of the dangers of error handling. As a precaution to avoid this, website owners should periodically test their error handling to make sure that everything works.
Webmaster Alerts
As mentioned before, notifications about errors can be delivered via email regarding every error. Sometimes, it doesn't make sense to have your inbox filled up with lots of e-mails. Another alternative is to create an RSS Feed. RSS stands for Really Simple Syndication or Rich Site Summary. It is like a news feed that delivers headlines along with a synopsis to users.
Using an RSS reader application, users can receive notification through their computer or cell phone about new error reports that get generated. The RSS reader can check the web server every five minutes for new issues. There are lots of code libraries available for creating RSS services on a website. It is also not too difficult to create your own custom service since an RSS feed is not much more than a dynamically-generated XML document that conforms to the RSS specification.
For even faster response times, it is fairly trivial to add a notification (or alert system) using SMS or text messaging to a cell phone number. So just like a pager was used long ago, site owners will be notified instantly whenever an issue occurs. Since it is a text message, information such as the page URL, or error type can also be sent in the alert. An implementation should be careful not to flood recipients with tons of text messages. A best practice would be to limit messages to once every 15 minutes and maybe limit the total number of messages per day to 25.
Error Notification Digest Emails
For websites that generate many error notifications per day, it might be less intrusive to aggregate all of the error notifications into one digest. A digest is a single report containing all of the error reports that were recorded for an entire day. Reports must be recorded either in a database or in a flat-file such as XML format. A scheduled process is run at the end of the day that collects all of the errors for the day and builds one big report.
This type of report cuts down on the amount of error messages that get sent out via e-mail. So a good compromise would be to send an e-mail digest each day and maybe have an Intranet or RSS feed for nearly instantaneous notification of errors. Of course, this type of notification requires that the webmaster or technical support person be in front of their computer or cell phone when the notification is received.
Refining Error Handling
There is no hard and fast rule for how error handling should be done. That being said, each situation is different and care should be taken to decide how to handle errors. Sometimes, we can take corrective action in the program code to get "around" the error. In this case, we may not even need to display any error at all.
When showing friendly errors, try to put yourself in the user's shoes. What kind of message would I like to see if I were on the page and a critical error occurred during processing? Should this error contain details on how to submit feedback to the webmaster? Should the error contain links to help and support documents that may suggest workarounds? Should this message contain a process that notifies users (probably via e-mail) once the problem has been resolved?
There are a myriad of different issues to consider when building customer error handling. If nothing else, we hope that this article has peaked your interest in developing a custom error handling system for your website. Errors are a nuisance to both website owners and site visitors. Making your site reliable and robust should be a high priority in your business.
Comments