Imagine, for a moment, a world in which we all wrote perfect code - a world in which we'd never have to spend precious time debugging our applications.

Okay, your moment's up. The world is, of course, far from perfect, and the reality is that we spend a fair amount of our time trying to chase down ColdFusion errors. After several hours of staring at the same lines of code, it's easy to become frustrated - especially if there's a deadline looming, or worse, a boss peering over your shoulder asking, "Is it ready yet? Can I demo it?"

My goal, then, is to keep you from throwing your monitor - or your boss - out the nearest window when you can't locate the problem. In this article we'll explore some of the tips, tricks, and general concepts for ferreting out those agonizing errors.

Relaaaaaax
The first thing I do if I'm having problems tracking down an error is to take a break. Frankly, it doesn't matter what you do: get a drink, smoke a cigarette, or just walk around outside. Sometimes a break is all you need. And when you come back, you'll often find the solution staring you in the face, causing you to wonder how you could've missed something so simple. So the next time you start to see red, take a few deep breaths and take some time away from code.

Enlist Help
Two heads - or three or four - are always better than one. If you're part of a team of developers and you've found yourself stuck, ask one of your co-workers to take a look; a fresh set of eyes always seems to help. Once again, when your colleague points out the problem, you'll probably find yourself wondering, "How did I miss that?" If you don't have anyone around to help, don't fret; there are still plenty of other avenues to explore.

In the age of e-mail and the Web, help is usually only a few clicks away. Think about it: you have numerous Web sites and mailing lists at your disposal, each of them with ColdFusion developers at the ready.

The forums in the developer section of Allaire's Web site (www.allaire.com) are an excellent resource as is the CF-talk mailing list available at the House of Fusion (www.houseoffusion.com). Both options usually lead to a flood of answers to your problem. The point is, whether you seek a co-worker's assistance or rely on a Web-based method, you're likely to find the solution.

Coding Tricks
Up until now, the tips we've explored have involved asking for help after the fact. But what about some preventive medicine? What about some pointers for when we're actually writing the code?

The first (and most fundamental) thing we can do is to use the debugging option on the ColdFusion server. This can be accessed by logging into the administrator and clicking on debugging (see Figure 1). We can select from a range of options, including Show Variables, Show Processing Time, Show SQL, and data source name. Each option gives us different information. The ability to see what form fields were passed in and what their values were can be of tremendous help. In addition, you can view what URL variables were passed in as well as their values. If you're having problems with queries, Show Query Information displays the record count, processing time, and the SQL statement for each query executed.

Use <cfabort>
I prefer to use <cfabort> if I'm having problems getting values into a database for one reason or another. And <cfabort> stops processing the page at the tag's location. When the tag is reached, ColdFusion outputs everything that was processed up until that time. When we want to check the values of variables right before they go into the database, we use a <cfoutput> block to output all their values, then use <cfabort> so the database query is never executed. From here, we can examine what might be going wrong with our variables. The code in Listing 1 illustrates how this might work.

Now we can view our variables and make sure all their information is correct. If not, we can readily see what's going on and correct those variables before they're inserted into the database. Using <cfabort> works anytime we need to stop processing - before we enter a loop or while we're looping. No matter what, <cfabort> will stop the server from processing a page.

Using a Marker
Most of the time, the error page generated by ColdFusion gives us some excellent insight into where the error is and what's causing it, but this isn't always the case. I find that if I'm working on a page and I want to know where the processing is going before it fails, I use a marker.

A marker is nothing more than a <cfoutput> tag with a word or a letter to be output. When I view my page, I look for the marker; if I see it, I know that the processing made it at least to that point before it failed. By moving this marker around, it's easy to determine where our code is failing. The following simple example illustrates how this works.

<!--- CF code above --->

<!--- Output the marker --->
<cfoutput>
We made it to here
</cfoutput>

<!--- CF code below --->

By using the marker, we can determine what line of code was the last to process properly before the error occurred. Another variation of this method is to use two markers and position them around blocks of code. This way we'll know if a particular block of code executed successfully. See Listing 2 for an example of this.

Now we'll know whether that block of code is the culprit. By moving these markers around, we can discover what code is generating the errors. In short, either of these methods will achieve the same goal: finding the code that's causing the errors.

Debugging Dilemma
We've covered just a sampling of the ways in which we can address the debugging dilemma. Numerous other techniques and third-party software tools are at our disposal, all of them designed to do one thing - find our errors and help us fix them. Perhaps a co-worker holds the key, or perhaps you'll find your answer on the Web or by using your own techniques while writing the code.

In any case, you'll soon find yourself in a better place, with a better application. Thus, while we can all continue to pursue that mythical white whale we call perfect code, we're probably a lot better off simply honing our debugging skills.

• Figure 1
• Source Code