Debugging ASP Scripts & Handling Errors

Home  »  ASP  »  Debugging You ASP Scripts and Handling Errors


     In ASP application, you can't usually crash the application the-ASP engine won't let it happen, but by default, any error that occurs on a page causes the ASP engine to stop executing the code on that page. To your users, it doesn't matter whether your application crashed or not. If users can't accomplish their goals, then your program is broken, no matter what the reason.

Contents

  1. How to Approach Error Handling?
  2. Raising Errors
  3. Debugging ASP Scripts
  4. Debugging Fatal and Non-fatal Bugs


How to Approach Error Handling?

One Way to approache the understanding of a large subject is to categories it into smaller chunks. There are 5 main categories of errors:

  1. Syntax errors
  2. Parameters/Input errors
  3. Logic errors
  4. Errors in external codes
  5. Resource errors
The goal in trapping these types of errors should be, in order of importance to.

  1. Keep your application from crashing
  2. Provide as much information as possible about the error
  3. Propagate errors back to critical decision point
  4. Degrade gracefully




Raising Errors

The following code fragment raises an error if a string is to long or too short:



You can raise errors at the top-level and you'll see the standard error display with your error information, but you are probably better of redirecting to an error page. The error page would display only those parts of an error that you want to reveal to your clients.




Debugging ASP Scripts

Despite your best efforts, errors occur during development and you must track them down. Debugging ASP is still awkward, even at the best of times.

There are several different environments for writing ASP scripts, only Microsoft's Visual InterDev_environment has debugging facilities. Writing debug output isn't dependent on any particular environment-u can use it effectively even with a plain text editor.



Output

Last Name Bintu
First Name Chaudhary
Email






The Email field does not occur. How can you find out what the problem is? Fist look at what you know:

  1. The code creates the Dictionary object properly: otherwise the first assignment would raise an error.
  2. The values are apparently assigned properly because no error occurred-but because of the way Dictionary object work, you can't be absolutely sure of that.
  3. The html code is well formatted-all the rows and columns appear in the table.

Next, look at what you don't know. You don't know if the Dictionary contains the Email value, or whether it just isn't showing up properly. One test is to write a loop that displays all the keys and values in the Dictionary. Inser the following code after the <body> tag, but before the <table> tag.




All the fields show up. Therefore, the problem must lie in the way the code references the Email value.

Output
Last Name Chaudhary
First Name Bintu
Email abc@gmail.com







Debugging Fatal and Non-fatal Bugs

While debugging your ASP application we need to watch for two types of bugs.

Fatal bugs: A fatal bug causes an abrupt end of the execution of a program

Non-fatal bugs: It does not halt the execution of a program; rather, it causes the program to generate the wrong output for a given input.

Debugging Fatal Bugs


Fatal bugs are defects in your code that cause that abrupt end of execution in your program. Fatal bugs are relatively easy to locate because when a fatal bug occurs, your ASP script will stop executing and an error message will be displayed. For this reason, anytime you can covert a non fatal bug into a fatal bug, it is in your interes to do so.

To see a good example of converting a non fatal bug into a fatal bug, compare listing 1 and listing 2.

Example 1 Non-fatal bugs



In Example,1, we commit an error of using an undeclared variable. note that line 3 declares the only variable as strName. Then line 4 refers to variable as strNme, a simple typo. Because we have noy explicitly declared a variable named strNme, this should cause a fatal bug. However it does not because we have not used option explicit. In lusting 1 two variables are allocated, one explicity (strName) and one implicitly(strNme). strNme is assigned the value Bintu, whereas strName equals the empty string. Therefore when line 6 outputs the value of strName, an empty string will be output. The output of Example 1 will be "Hello". because Example 1 executes completely and we did not receive the output we expected, the bug is classified as a non fatal bug. although the typo on line four in Example 1 might be easy to catch now, it becomes much more difficult when you have such an error on an asp page with hundreds of lines of code. it is in your favour, then to turn all non fatal bugs into fatal bugs. Example 2 contains the exact same code as Example 1. excpt for adding option explicit on line 2.


Example 2 Fatal bugs



Example 2 uses option explicit thereby requiring that you explicitly declare all variables. Therefore when line 5 is reached and an undeclared variable is referenced(strNme), an error is generated and the script ceases execution. This is an example of fatal bugs because your ASP page stop executing after it reqch line 5 in Example 1 we were not explicitly notified of the bug. However with Example 2, after we run the ASP script we are immediately aware of the bug. The output of Example 2 when viewed through a browser would be:




Debugging Fatal Bugs


Non-fatal bugs are not necessarily more difficult to fix than fatal bugs but are always more difficult to locate because fatal bugs list the exact, offending line number. The only way to catch non-fatal bugs is through testing, testing and more testing. it's important that you test your ASP page using inputs that fall into each of these four categories.

  1.   Expected input values
  2.   Near-boundaries input values
  3.   Boundary input values
  4.   Unexpected input values









Share on Google Plus
    Blogger Comment
    Facebook Comment