ASP 101 - Active Server Pages 101 - Web01
The Place ASP Developers Go!

Windows Technology Windows Technology
15 Seconds
ASP 101
ASP Wire
VB Forums
VB Wire
internet.commerce internet.commerce
Partners & Affiliates
ASP 101 is an site
ASP 101 is an site
Internet News
Small Business
Personal Technology

Corporate Info
Tech Jobs
E-mail Offers

ASP 101 News Flash ASP 101 News Flash

 Top ASP 101 Stories Top ASP 101 Stories
Connections, Commands, And Procedures
What is ASP?
VBScript Classes: Part 1 of N

Watch your Paths with Server.Transfer
Show All Tips >>
ASP 101 RSS Feed ASP 101 Updates

Quick Tips

Disable Buffering to Simplify Debugging

Recently, I was working on a script that was designed to take a set of data as input, apply some formatting to each record, and output the results. While the concept is simple enough, the problem was that the data being provided to the script was not quite uniform. Not only was the data being pulled from a text file which used spaces as delimiters and included data which contained spaces, but we also occasionally ran into records that were simply incomplete.

So as I saw it, I had two options. I could add tons of error handling in an attempt to handle every possible failure or I could simply omit the error handling, run the script, and see what happened. Well we all know what happened... I got an error. In this case it was Microsoft VBScript runtime error '800a0005' - Invalid procedure call or argument: 'Left'. Anyone who's done any string wrangling in VB has probably seen this error, but it's not very helpful in trying to find out what data caused the error. What would be helpful in that regard would be being able to see the output of the records that got processed before the error happened. And how do we do that? Why we disable buffering of course.

If you're not familiar with buffering, you may want to take a moment and read our tip which recommends enabling buffering to increase performance: Set Response.Buffer = True.

By setting Response.Buffer = False, we tell the server to return the output of the script as it is generated. That means we'll actually see all the data that the script has processed right up until the error happens. This allows us to easily find the problem data by simply taking the last record processed before the error and finding the corresponding entry in the input. Then we simply look at the next record and we've almost certainly found the one causing the problem.

While I don't recommend this type of approach on public sites or if others are going to be using the script, it can be an invaluable debugging tool and a huge time saver if you're trying to find and eliminate problems.

Previous      Show All Tips      Next

If you have a tip you would like to submit, please send it to:

Home |  News |  Samples |  Articles |  Lessons |  Resources |  Forum |  Links |  Search |  Feedback
The Network for Technology Professionals



Legal Notices, Licensing, Permissions, Privacy Policy.
Advertise | Newsletters | E-mail Offers