If you have developed any kind of serious web-based application (or any type of application for that matter), you know the joy of trapping errors for anything that the user might do. Bad password, letters where numbers should be, etc. Not rocket science.
Some errors are “above” the code though, especially in web development. For example, how about a script error, or maybe a 404 error? As your website grows, it is important to test your errors as well, to ensure that they are still working and valid.
Most time, error trapping is pretty straightforward. From most web developers view, there are two main types of errors: invisible and visible.
Wait, what?
Visible errors are pretty straightforward. These are the errors that were trapped by the program or script, but the code doesn’t know how to handle it. Invisible errors are those that are trapped and automatically handled by the script, with no user notification or interaction. A login script is a perfect example of both of these.
In a login check, the user has entered their user name and password. In 99% of these cases, the user name is not case-sensitive, while the password is. So if the user enters any of the following for the user name it will won’t matter:
MyUserName
Myusername
myusername
MYUSERNAME
If we query the login databse for the user name without conversion a single case (or use of the LIKE statement), we’ll get a SQL error when the value can’t be found. So in this case, we account for the varied case of the user input.
However, if the user name is not found at all, or if the password is incorrect, we’ve got to let the user know in a nice, friendly way that the information was incorrect. Which of these would you like to see?
Nice, trapped error:
Oops!
The username or password was invalid. Click your browsers back button to try again.
Ugly, untrapped error:
ADODB.Recordset error '800a0bcd'
Either BOF or EOF is True, or the current record has been deleted.
Requested operation requires a current record.
Whoops! Someone didn’t trap the errors correctly. This type of error is usually pretty easy to catch in your scripting. However, did you know there was another way to trap this? Maybe let your web server catch it instead?
With Windows Internet Information Services, or IIS, you can designate custom error pages for just about any kind of error that would be sent back to the client browser. In the above example, a “500 – Script Error” would be returned to the client browser. In the event of a page not found, a “404 – Not Found” error code would be returned.
Usually these are accompanied by a cryptic and (to the user) uninformative page full of errors that is really of no help to the user. They will do one of two things: Move on to someone elses web page (Not good), or hit the back button and try the process again, which will probably lead them back to the error, then off to some other site (again, No!).
So let’s have IIS take care of this for us. With IIS 7.5, it’s pretty straightforward to set a custom error. Simply create a page to land on, then using the following steps, instruct IIS to send users who receive the 404 to the target page.
- Click on the Web Site
- In Features View, double click on Error Pages
- Click Add.. under Status code: type 404
- Click Insert content from static file into the error response, type 404.html
- Click OK
- Now, to set detailed error locally for the 404
- Click on 404 error page we configured and click on Edit Feature Settings…
- Under Error Responses, select Detailed errors for local requests and custom error pages for remote requests, click OK
From now on, when your user experiences a page not found condition, they will be redirected to the page you specified, rather than the old, ugly error message. You can perform this magic for 500 series errors as well.
Be careful, though. It can get easy to use this as a crutch. Rather than trapping the errors properly, and guiding the user to the right solution, some folks are simply using these built-in error handlers to drop users on error pages with no explanation. Users will get tired of this. After all, who wants to go to a web site that is so full of errors that all you see is “an error occured”.
Regression testing is important as well, as mentioned up top. As your site grows, it is very important to review the errors from time to time, and ensure that they are still relevant, or do they need to be update. Perhaps the condition that causes the error has changed, and the info presented to the user is no longer valid.