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
