Back In My Day...

When I graduated from college in 1995, the World Wide Web was still a new medium and I was spending all of my time working on client side applications. All of my course work and indeed all of my work for pay consisted of client side desktop applications, and 2 and 3 tier architectures were all the rage. Some new application that was available at school called 'NCSA Mosaic' was used to point at these horrid looking hyperlinks detailing the physics of Star Trek, the life story of Marci's three pet kittens or, if you were lucky, some rather informative but very dry material discussing esoteric pieces of academic arcana. Just about anything accessible from these application was hosted at http://www.<InsertUniversityNameHere>.edu/~<YFLSI> (that would be Your Five Letter Student Id). It was a nice curiosity, but other than page counters, nobody had anything resembling dynamic content.

Somewhere between then and now desktop applications have become less important for most day to day activity. The web is pretty much where it is at, both for users at home finding information and as a medium for developing and deploying corporate applications. In all that time, some of the most effective debugging techniques for all this nifty software have pretty much stood still. Most of the real work lies in narrowing down the problem and finding the true source. Fixing it is usually the easy part. Here are some debugging tips no web developer should be without.

printf debugging will never die...

Most web applications consist of a set of web pages or scripts that dynamically generate HTML or some other markup. They may from time to time call into server side components (Usually via CGI or COM) to do more interesting work, but a lot of time seems to be spent in pages written in languages that give 'real' developers the heebee-jeebees like PHP or VBScript. The beauty of these languages is that they are pretty simple and accessible for most people of slightly above average intelligence. One big drawback of these languages is they are pretty simple and accessible for most people of slightly above average intelligence. If you showed these folks some nasty perl regexes or a beautiful piece of C they would blubber like babies. You put FrontPage and a simple yet powerful scripting language in front of these people and they think they are the second coming of Dijkstra

The real fun begins when one of these cowboys stumbles upon a pretty good idea, implements something that somehow works and then it eventually finds its way to the development staff to either support or roll into a product as a new feature, sometimes with little or no alteration because it is "good enough", which is Senior Management speak for "We know it probably sucks, but hey, we don't have to maintain it. Have fun." At this point the poor unsuspecting developer is looking at this pile of crap when they get their first customer support issue.

Fear not intrepid developer. Think of a web page as a blank canvas upon which you can put just about anything you want. This includes all of the diagnostic information you could ever want. It isn't pretty, but a detailed trace of what the code is doing is usually the best bet to figure out what is going on. Response.Write and echo are your friends. Use them. Write out all the nasty details you need to figure out what the problem is. SQL queries, user information, parameters, and so on. And this is just on the server side. Any information that isn't critical from a security or application standpoint can even be written out as HTML comments during the normal course of the application. This way a user can send you the source of the page as part of a bug report. On the client side, you can use some java script to create s simple log window so everything is in its own tidy location.

Take a hint from those old school Unix folks who write programs with a verbose mode which logs just about everything the application even thinks about doing. Doing this in a web application is pretty easy to do given that spewing forth loads of text is what web applications are good at anyway.

Hit The Page Directly

When a browser has trouble loading a page, it will usually tell you so and will even give a good indication, most of the time, what it thinks is wrong. This fact usually gets lost in the shuffle when debugging a multipage application that may include other pages or calls another page to do some work and then returns. Or maybe the application uses frames so all you see in the URL is the main page and you don't think about the underlying pages because all you see in the address bar is http://myServer/main.html.

One example I dealt with recently tied to this was an application that was not updating some status codes after some numbers were submitted to the database. The developer was pounding away at this thing, showing me all the places where it might be failing and showing me that the old page worked fine but the new one wouldn't and what could possibly be wrong? In this case the page was coming up in a separate window as a popup and you could see the title bar say "Page could not be displayed" but you couldn't see the page contents at all. Since we knew the name of the page it was loading we simply typed that into the address bar and the browser was kind enough to tell us that some variables were not defined. For those that have done lots of ASP programming, you're probably thinking "Gee, was he using Option Explicit?" And he was. So we took that out (the old page didn't use Option Explicit) and everything went humming along just fine. Whether or not Option Explicit should be used in ASP pages by default is another discussion. The point here is that I have no idea how long he had been spending trying to figure out what the problem was (it was a while because I got an e-mail about it on Monday morning and it was still there Tuesday afternoon when I finally had a chance to look at it), but by simply looking at the page, it took about 10 seconds to diagnose and fix.

In addition to regular web pages, hitting a web page directly with the browser is a good first step in lots of instances. If you have an application that is having problems talking to a web service, find out the link it is supposed to hit, fire up a browser and paste the link in. See what comes back. If you get a listing of the service routines or some other output that looks as if you would expect, you still have to do some work to find the problem. In a lot of cases, though, this simple step is enough to find a problem. This is an extremely simple step that will eliminate a lot of unnecessary work in a lot of cases. Take the 10 seconds to type in the address into the URL of your favorite browser to see what happens before diving headlong into the code. Worst case is you lose 10 seconds. Best case is you save a day and a half of unnecessarily slogging through code trying to figure out why something isn't working.

Getting Page Parameters

Right now, please put the cursor in the center of this page and right click in your browser. One of the picks on the menu should be something like View Page Info; (Firefox) or Properties (IE). Pick it. You should get a window that comes up. One of the entries should be named URL: or Address:. Now this page isn't very exciting. It is a simple static page. However, lots of web applications pass parameters in the URL that are read by the page when it is loaded. In the case of a single page, you can usually get this off the address bar if it is visible. If the address bar is not visible, or you are using a web application that uses frames, this wonderful right click menu option will give you the entire URL, parameters and all. You will know which page to start debugging and have a set of parameters that reproduces the problem to boot. You can copy this entry out of the dialog and paste it into a new browser instance, giving you a much narrower path to follow in finding bugs.

View the Source

Similar to right clicking and getting page parameters, you can right click on a web page and view the source of the page. This is most helpful for javascript errors. When you load a page in IE, for example, if there is a javascript error, will put a little yellow icon in the status bar that you can double click and get a dialog like this

Right clicking on the page and picking view source show you the source of the page. You can go to the appropriate page and see the line that is causing the error. This is especially helpful in dynamically generated pages, such as php or asp, that use a lot of statements to programmatically create the output. Comparing the output to the code that is generating the output will often quickly lead you to the erroneous logic in the program.

Don't forget your roots

As you can see from the above, many of the most basic things you learned about debugging in your computer science classes using printf statements and tracing through output will be valuable, no matter the programming medium. While many environments do allow for more involved debugging techniques, allowing you to step through code, get into compiled objects, etc., these techniques will work on just about any platform using any combination of web server and language. If all you have is your customers application and a text editor, you can still make a good effort at troubleshooting problems with these simple, time tested techniques.