Dave Carabetta Blog Banner


June 7, 2006

Do You Even Use ColdFusion's Debugging Info?


So I've been heads down on a project that really should have been scheduled for a one month development period even though they only gave me 7 days (sound familiar?). In my development environment, I have all the debugging features turned on with the exception of the "Report Execution Times" option (as I've noted before, if you're doing heavy CFC-based work, do yourself a favor and shut that option off or you may go nuts).

During one of my late night coding adventures, something occurred to me: I think I've looked at the actual debugging information (the stuff below all your markup, not log-related stuff) exactly twice. Seriously. And believe me, it's not because I'm a flawless coder...my exeception.log file is gi-normous! But the reality is that it's immensely more helpful to me to use a combination of cfdump and cflog along with the standard cfoutput/cfabort tags to really get at the information I need to diagnose a problem. Coupled with CF 7's new "result" attribute for enhanced query information (where you can get at execution times, bind variable values, etc.), I really don't know what the utility of ColdFusion's built-in debugging output is. Listing all the query execution times at once is about all I can think of at the moment.

Frameworks are becoming more and more popular in the ColdFusion community, which is great. But using those frameworks usually means that the form and url scopes are unified, which makes their individual listing in the debug output pretty much useless. If I really need to see the individual scopes, I can set up a code snippet shortcut to output the following:

<cfdump var="#url#" label="URL Scope" />
<cfdump var="#form#" label="Form Scope" />
<cfabort showerror="Here." />

It seems like all I really get anymore from turning on debugging is the increased overhead incurred by enabling the debugging service. And who needs that? So that got me thinking even more. What would I like to see? What would you like to see? Personally, I'm still not sure. I've made no secret that I'm a big Model-Glue fan. Maybe something akin to Model-Glue's debugging output where it shows all the events that were executing along the way in the order in which they were executed? Obviously, for non-event based frameworks, that's pointless, but I guess what I'm saying is that it's about as close to run-time debugging as I need. I'm pretty stumped though otherwise.

What do you think? Do you find yourself using the native debugging output in your development? Or do you use the cfdump / cflog / cfoutput / cfabort tags like I do? More importantly, how can the built-in debugging be improved? Adobe's actively working on Scorpio (aka ColdFusion 8), so this is the time to get your wishes in.

Posted By Dave on June 7, 2006 at 4:00 PM
Related Categories: Model-Glue, Frameworks, Oracle, ColdFusion, Technology, Adobe
Comments (12) | Print | del.icio.us | Linking Blogs


Related Blog Entries

Comments
[Add Comment]
SiamesePurr771's Gravatar I use the debugging info all the time. I frequently look to see if queries have run or are being pulled from a cache, to see if specific form fields are coming across (like file uploads which are not shared in those frameworks' unified scopes) and of course, the cgi scope since I have not (yet) memorized all the keys in that scope. But that's just a habit. I can certainly see how one might not be in the same habits yet lose no efficiency.

-Purr
# Posted By SiamesePurr771 on 6/7/06 at 5:03 PM
Scott Stroz's Gravatar I use debugging all the time, and pretty much for the same reasons. Especially if I am working with code that I did not write (which I am doing a lot of right now)
# Posted By Scott Stroz on 6/7/06 at 5:14 PM
Barney Boisvert's Gravatar The exception listing in the debugging output is very helpful, though I agree about most of the rest of it. The CFTRACE output is also helpful on occasion, where you can't do the CFDUMP/CFABORT thing, because you need to trace flow not a checkpoint.
# Posted By Barney Boisvert on 6/7/06 at 5:36 PM
Joe Rinehart's Gravatar I'm right with you an all of this, but I use one thing in MG heavily:

If you're in a controller in an MG app, you can do arguments.event.trace("label", someValue) and it'll add the value to the MG debug info. Complex values get <cfdump>'d.
# Posted By Joe Rinehart on 6/8/06 at 1:10 AM
Ben Nadel's Gravatar I use the page debugging to see query records/performance. For everything else I use CFDump. One of the best best best things about CFDump/CFAbort is that if you run a CFDump then CFAbort inside a CFSilent tag, then you actually get to see the buffer created during the CFSilent. This makes debugging inside CFSilent tags a total breeze.
# Posted By Ben Nadel on 6/8/06 at 9:42 AM
Rob's Gravatar As an instructor, I find the debugging info to be extremely helpful. However, as a developer, I'm increasing using other methods such as cfdump for one very big reason - the display of the debugging info is worthless if you use pure CSS layouts, since the old-school table-based layout used by the debugger causes it all to fly to the top of the screen, actually under my content, thus making it unreadable.
# Posted By Rob on 6/8/06 at 10:23 AM
Dave Carabetta's Gravatar Joe, that's exactly what I was thinking about....of course, not until after I hit the "Post" button! I use the trace() feature extensively myself.
# Posted By Dave Carabetta on 6/8/06 at 10:23 AM
Scott Stroz's Gravatar Rob -

I use CSS layouts all the time, and my debugging info is not covered up by the page. I think I remember reading something about absolute positioning causing an issue similar to this..
# Posted By Scott Stroz on 6/8/06 at 10:32 AM
Dave Carabetta's Gravatar Rob, do you know that you can edit the debugging template yourself? As Scott mentioned, there have been some threads on cf-talk and elsewhere that have alluded to absolute CSS layouts causing problems. However, if you go to your WEB-INF/debug directory in your CF installation and open up the classic.cfm template, I think you can put a [div style="clear: both;"][/div] to force the debugging to occur after all the CSS stuff.
# Posted By Dave Carabetta on 6/8/06 at 10:52 AM
Steve Nelson's Gravatar Heck yeah i use debugging output! CF debugging output is badass. But then again i'm an old school CF developer i've been using CF debugging for 10 years now. It's second nature to me. There are still a million things wrong with the way CF outputs debugging information, but overall it is mucho-excellente.
# Posted By Steve Nelson on 6/8/06 at 3:38 PM
Dave Carabetta's Gravatar Hey Steve. I'm hitting the 10 year anniversary of my CF experience myself, and I'd agree that for about the first 9 years that output was indispensable. I guess that in the last year or so, as I've gotten into more framework-based development and CFC-heavy development, I've found it to be less and less helpful by default. It's not pointless, mind you, but I just feel like it's not outputting the sort of information that I need in my current work.

The Model-Glue framework has this awesome ability to add all datatypes to its debugging output via a trace() method -- structs, arrays, cfdump, etc. All I need are those trace() lines and can then let the page run to completion -- no cfaborts needed. That makes me more productive. That's something I'd like to see in CF 8. Right now, I'm stuck with what's built in, which is a little bit to "basic" for my work. I'm sure there are other things, but they're just not jumping out at me at the moment.
# Posted By Dave Carabetta on 6/8/06 at 3:49 PM
Sam Farmer's Gravatar I feel pretty much the same way but I still always have it on when I'm developing...it just feels wrong to not!

Good suggestions for CF8.
# Posted By Sam Farmer on 6/8/06 at 4:40 PM
[Add Comment]

© Dave Carabetta, 2005-2008. This blog licensed under the Creative Commons License. Some rights reserved. This is a personal weblog. The opinions expressed here represent my own and not those of my employer. Blog software provided by Raymond Camden.