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.
Archived Comments
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.
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.
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.
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.
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.
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.
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.
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 :)
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.
Well that is pretty nifty there Mike. What a cool idea!
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>