Quick and dirty debugging tip for Flex/ColdFusion

There are multiple methods of debugging applications, including the very cool FusionDebug, log files, ServiceCapture, and the debugging rolled into Flex Builder 2 itself. Here is a quick tip for another method to use. It's ugly - but effective.

Modify your onError to dump the errors and log to a file like so:

<cffunction name="onError" returnType="void" output="false">
   <cfargument name="exception" required="true">
   <cfargument name="eventname" type="string" required="true">
   <cfset var temp = "">

   <cflog file="my app" text="#arguments.exception.message#, #arguments.exception.detail#">
   <cfsavecontent variable="temp">
   <cfdump var="#arguments#">
   </cfsavecontent>
   <cffile action="write" file="c:\myapp.html" output="#temp#">
   <cfdump var="#arguments#"><cfabort>
</cffunction>

I wrapped a dump of the arguments (which contain my exception) and simply save it to the C drive as an HTML file. I then have this file open in my browser. As I debug, I can simply reload the tab in Firefox to see what the latest error was.

I find this especially useful when the exception message is a bit too vague. With the dump I get the full trace of files where the error occurred.

Let me be absolutely clear: Do not use this code in production. It isn't nice. It doesn't play well with others. It runs with scissors. You get the idea. But I thought I'd share.

Comments (11) Jan 29, 2007 1:33 PM Views: 2780

Comments

[Add Comment]
OK, I'll take the risk of sounding naive: what exactly are the dangers of using cflog in your error code in a production system? This seems like a pretty good tactic to me.
# Posted By Tom Mollerus | 1/29/07 3:11 PM
Its been a while since I worked in Flex, but I also liked to throw a dump method into components when developing a flex app. The method looked like this:

<cffunction name="dump" output="false" access="remote" returntype="void" hint="i dump">
      <cfargument name="content" type="any">
      <cfset var theDir = getDirectoryFromPath(expandPath("*.*"))>
      <cfset var theFile = theDir & createUUID() & ".xls">
      <cfset var theOutput = "">
      <cfsavecontent variable="theOutput"><cfdump var="#arguments#"></cfsavecontent>
      <cffile action="write" file="#theFile#" output="#theOutput#"/>
   </cffunction>


Again, not the prettiest but its a similar idea for taking a look at what a certain grid or flex data element contained in a familiar format (cfdump).

I would like to get my hands on Nimers debug panel if I get back into Flex development anytime soon.
# Posted By todd sharp | 1/29/07 3:25 PM
Tom, I didn't mean the cflog, but the cffile operation. That was the main point of the blog post. (Remember I said that cflog was text based?) If that isn't clear, let me know.
# Posted By Raymond Camden | 1/29/07 3:28 PM
I normally use cfmail and dump the arguments and cfcatch scope into an HTML email and that has been the best way for me. I have been doing it this way since I started doing RIA's with Flash MX.
# Posted By Clint Tredway | 1/29/07 3:31 PM
Ray,

I did this very same thing a while back, only I did my file dump like this:

<cffile action="write" file="c:\debug\#replace(replace(xmlFormat(CGI.Script_Name), '/', '_', 'ALL'), '.', '_', 'ALL')#.html" output="#mydbgOutput#">

then, I got file names like this: rootdir_subdir_dubdir_file.cfm.html

then I could look at all my templates being called and what debug output they had. Like you said, its kinda resource heavy writing files for each request, but makes debugging easier, and wont break web layouts with popups or divs.
# Posted By Justice | 1/29/07 3:35 PM
Clint, mail is what I normally do in production. But for dev - this worked out well as I didn't have to wait for the mail to arrive. Plus - I don't have a mail server on this local box.
# Posted By Raymond Camden | 1/29/07 3:40 PM
Very true, I do a file dump when I dont have access to a mail server, but when I do, even in dev, I do mail dumps. I have also been using FlashTracer in FireFox to get errors as well.
# Posted By Clint Tredway | 1/29/07 3:45 PM
Ray,

I am using exactly the same technique ATM for debugging functions called from an Async event gateway.

I am using CFLog throughout the app to log events and errors to a log file, but there are definately times that having the full stack trace etc. is invaluable.

Again, as other people have mentioned, we use cfdump / cfmail within live apps, but during initial dev, having to wait ~3 minutes to see the error, is not acceptable :)
# Posted By Danlance | 1/30/07 6:55 AM
I did something similar, although I wrapped the error in a cfdocument tag with a filename attribute and saved as a swf. I then was able to pull in the swf right into my flex app.
# Posted By Mike Collins | 1/31/07 7:23 AM
Well that is pretty nifty there Mike. What a cool idea!
# Posted By Raymond Camden | 1/31/07 7:42 AM
To keep from having to maintain differing versions from my testbed to my production, I could make a minor modification to that code (see below) which would only create the file on my testbed (ie. localhost) environment.

I could also throw in a "cfelse" that would run the "cfdump" to cfmail if it is NOT on the testbed. Used this methodology when I was working with application.cfm at Discovery. Worked well.

<code>
<cffunction name="onError" returnType="void" output="false">
<cfargument name="exception" required="true">
<cfargument name="eventname" type="string" required="true">
<cfset var temp = "">

<cflog file="my app" text="#arguments.exception.message#, #arguments.exception.detail#">

<cfif cgi.servername is "localhost"><!--- Sid's Mod --->
<cfsavecontent variable="temp">
<cfdump var="#arguments#">
</cfsavecontent>
<cffile action="write" file="c:\myapp.html" output="#temp#">
<cfdump var="#arguments#">
<cfabort>
</cfif><!--- End of Sid's Mod --->
</cffunction>
</code>
# Posted By Sid Wing | 1/31/07 5:33 PM
[Add Comment]