Errors happen. Regardless of how skilled a given programmer might be, there is no way he can create truly bug-free code. Programming errors can be broken down into two broad categories: logical errors and implementation errors. Before starting to actually write code, a developer must have a solid understanding of what application she is creating, and the logic behind this application.
For example, when creating an e-commerce web application, a developer might decide that once a user decides to purchase an item, he is taken directly to a page to enter his billing and shipping information. Many users today are used to a shopping cart system, in which they can purchase multiple items online and then proceed to a “check out” page, where they can review a summary of the goods being purchased and enter the needed billing and shipping information. By not providing a shopping cart system, your users may find your site confusing and burdensome to use. Logical errors are often high-level errors, costing immense time and money to fix, since they are usually not caught until late in the product development cycle.
Implementation errors are those errors residing in the actual code. In an e-commerce site, if not all of the items selected by the user appear in the summary listing on the “check out” page, an implementation error has occurred. To summarize: flaws existing within the high-level view of the application are logical errors; errors or bugs resulting from the implementation of an idea or feature into code are implementation errors. Implementation errors are easy to detect: if the program crashes or produces incorrect output, an implementation error is at fault. Logical errors, however, are much more sinister and difficult to detect.
This chapter does not focus on how to reduce the number of errors you, as a developer, commit when writing code. Rather, it looks at how to gracefully handle these errors when they inevitably occur. We’ve all seen the patented Microsoft Blue Screen of Death one too many times, and all know the frustration involved when a program fails to gracefully handle an error. Since bugs and errors in any decent-sized application are certain, it is vitally important to be able to respond to these errors smoothly when they occur.
We’ve already looked at the two broadest categories of errors: logical and implementation errors. Implementation errors are often described in terms of halting errors and non-halting errors. Halting errors cause the premature termination of a running program, whereas nonhalting errors produce unreliable or unpredicted output but allow the continuation of the program. Halting errors can be further divided into runtime errors and compile-time errors. Runtime errors are those errors that occur during the execution of a program, while compile errors occur during the compilation process of the program.
When an ASP script is requested, it goes through a two-phase process. First, the script is compiled into an executable version. Any syntactical errors are caught here; these are referred to as compile-time errors. For example, the following VBScript syntax, which is illegal, will generate a compile-time error:
<% @LANGUAGE="VBSCRIPT"%>
<%
Dim strScott
strScott = "Mitchell 'This will cause a compile-time error since the
'assignment to the string strScott is missing a
'closing quotation mark
%>A syntactically correct script may be free of compile-time errors, but it can still contain runtime errors. Runtime errors occur when some unexpected event happens during the execution of the script. For example, dividing a number by zero is legal syntax in VBScript (therefore not generating a compile-time error), but will nevertheless generate a runtime error since the result of division by zero is undefined. The following code snippet will generate a runtime error:
<% @LANGUAGE="VBSCRIPT"%>
<%
Dim iUndefined
iUndefined = 1 / 0 'This will cause a runtime error since the division by
'zero is undefined
%>Runtime errors are not always the fault of the programmer who developed the script that generates an error. For example, imagine that you create an ASP page to display the contents of a particular SQL Server database table. Even though your script may be flawless, containing no logic or implementation errors, if the database table being queried is renamed or the entire database is deleted, your once-perfect script will now abruptly terminate when attempting to query a non-existent database table.
A more general term for a halting error is
exception
.
An exception, in the most general terms, is something unexpected. For
this chapter, the definition of exception is narrowed to an
unexpected event that halts script execution. Therefore, both an
implementation error and an unexpected event (like a database table
being renamed) qualify as exceptions. It is every programmer’s
goal to gracefully handle exceptions.
You may have noticed that I’ve been using the phrase “gracefully handle an exception” quite a bit, and as a curious reader, you may be wondering what I mean, exactly, by “gracefully.” When an exception occurs, a number of things can happen. Since the developer does have a bit of control over what happens following an exception, the worst course to follow once an error occurs is to display some illegible, confusing error message to a user who may not be computer-literate.
Rather than presenting the end user with a perplexing error message, one option is to provide a more readable, friendlier message. This message would not need to alert the end user to the technical aspects of the error, but rather would let the user know a problem has occurred and the developers have been made aware of the problem. It could also suggest other web pages to visit, or could contain a link for more information (if you add the above) and the email address of the technical support team.
Tip
Error messages are usually unreadable to the end user because they usually contain information to help the developer detect the cause of the error. While an error message like:
General Protection Fault in module 256_1024.DRV
is not readable for the end user, it lets the developer know the driver in which the error occurred. In this chapter we will examine how to create readable, friendly error messages for the end user and how to provide detailed error information to the developer!
Displaying an understandable error message to the end user is usually the best thing that can happen when an exception occurs. However, there are rare times when an exception can be circumvented. That is, if a particular exception is detected, a sequence of steps can be undertaken to dance around the problem, continuing the execution flow, so that to the end user, it appears as though no exception had occurred. For example, imagine that every week your database’s data was backed up to a secondary database. If, in your ASP page, you have trouble connecting to the primary database, rather than displaying an error message, you could show the user the backup data. Granted, this data might be out of date, and you would want to let the user know they are viewing dated information, but showing the user something useful is better than showing them an error message.