By Tom Parkhurst

The debugging process can be painful for both novice and seasoned
developers alike. The next three newsletters will cover the basics of
debugging ASP code. While I can't promise that the methods I'll
describe will ease the pain, they will get you through the effort with
far less bruises.

Debugging can be boiled down to one simple phrase: Got a bug, find the
bug, fix the bug. Defined as any unplanned and/or unexpected result,
a "bug" can take the form of a blatant VB Script error popping up in
the browser window or something subtler, like the transposition of two
database fields?contents. Any time the implementation does not match
the design, considered it a bug.

Not to say that all bugs are necessarily bad things. When encountering
a bug that prevents the implementation from matching the design, ask
yourself: "Do I really want to fix it?". The oft abused phrase, "It's
not a bug, it's a feature!", should sometimes be taken seriously. If
what you actually built seems good, then perhaps you should
advocate "for" it rather than "fix" it. I have done this often with
good results.

When a bug really must be fixed, two possible scenarios generally
unfold:

1. You know your code so well that you immediately know what to fix
and where to fix it. Usually, a VB script error identifies the
problem and its location. Wouldn抰 it be a beautiful world if
all debugging were that easy?

2. In the more common debugging scenario, you don't have a clue.
The rest of this discussion will address this case.

Sound code design is the key to successful debugging. Modular code,
which separates functionality into small subprocedures and functions,
shortens the debugging cycle considerably. Functions and subroutines
present distinct pieces of code that can be tested and verified
separately.

One standard debugging technique temporarily inserts a Response.Write
in a function or subroutine抯 first line displaying the parameters that
were passed in. A matching Response.Write displays the results of the
function before you return. In fact, inserting temporary
Response.Write statements is the primary debugging method used in ASP.
A rather simplistic approach, but it works and provides immediate
feedback.

For example, I have inserted Response.Write statements into the
following function code.

Function calculateTax( fltCost, intZipCode)
Response.Write( "Entering calculateTax(" & fltCost & "," &
intZipCode & ")" )
...
(Lots of code that searches database for zip code, extracts %,
and calculates tax)
...
Response.Write( "Exiting calculateTax = " & calculateTax )
End Function

The two Response.Write statements provide all of the data that is
passed in and returned from the function. As a side effect, the
inclusion also verifies that the function is actually called -- many
times the key to the bug.

The drawback of debugging by insertion is that you must return to the
code and remove the Response.Write statements before releasing your
code. A better approach would be to create a method for turning these
display statements on and off as needed. Next week, we will discuss
expanding debugging by insertion to implement code tracing that can be
enabled or disabled through flags.