[FDS-121] FusionDebug: Feature Focus – Breakpoint Conditions & Hitcounts

Breakpoint Conditions & Hitcounts

FusionDebug breakpoints now have conditions and hitcounts, further controlling when they fire. This article will demonstrate these features.

Conditional Breakpoints

Introduced in FusionDebug 3.0, conditional breakpoints allow you to halt an application when a certain condition evaluates to true. For example, in a loop you could use a conditional breakpoint to halt when a variable equals a specified value. The condition used can be any form of CFML expression, anything that can be used in a <cfif> tag can be used as a condition. Advantages of conditional breakpoints include:

• Less time debugging; No need to step through long loops to get to a particular iteration.

• Prevents convolution of production code with debug code. To stop on an iteration or when a condition evaluates to true without conditional breakpoints you would need to add <cfif> tags to your code and set a breakpoint in the body of the tags. One of the advantages of a debugger is the alleviation of extra code for debugging purposes.

• Removes the need to disable breakpoints for some test cases, for example you might only want to stop a page on some specific input.

An Example

Given the following code:

<cffunction name="DoSomethingWithLastName">
	<cfargument name="lastname" type="string">
	<!--- Do something with last name arg --->
</cffunction>

<cfquery name="qry" datasource="test1">
	SELECT last_name FROM emp
</cfquery>

<cfloop query=qry>
	<cfset DoSomethingWithLastName(qry.last_name)>
	<cfoutput> #qry.last_name# <br> </cfoutput>
	<cfflush>
</cfloop>

Suppose we knew there was a bug somewhere in the “DoSomethingWithLastName” function, and we knew it happened when the last name of “Smith” was used as an argument. We could add a breakpoint on the line of the call to the function and set the following breakpoint properties:

This means that the breakpoint will only fire when qry.last_name equals “Smith”. If we now run the page, we see this:

The page has stopped on row 9 of the query loop, where the last_name field equals “Smith”. We can now step into the function and find the cause of the bug. Note that this is a relatively small query but could be thousands of rows. Using a non-conditional breakpoint in this scenario is time-consuming and unfeasible, plus you could end up resuming past the row that contains “Smith”.

Other useful examples of breakpoint conditions:

• isdefined(“url.length”) and (url.length + 1) gt 10. This can be used to halt the page when certain url parameters are used, in this case length > 10.

• DateCompare(yourdate, CreateDate(2009, 01, 01)) LTE 0. This will halt the page when “yourdate” is before 1st January 2009.

• http.remote_addr eq “127.0.0.1” or http.remote_host eq “localhost”. These conditions will allow another machine to request the file without the breakpoint firing. Useful if you have to demo the file to another person but don’t want to disable your breakpoints. Note, on Railo use cgi.remote_addr eq “127.0.0.1”.

Read more about Conditional Breakpoints

Hitcounts

New to FusionDebug 3.0.1 are Breakpoint Hitcounts. Hitcounts are a specific type of condition for a breakpoint separate from an actual breakpoint condition. A breakpoint with a hitcount will only fire after a certain amount of hits. This is useful if you have no variables to use in a condition.

Hitcounts can be used along with conditions to fine tune the firing of the breakpoint. For example consider the following loop over a query variable:

5: <cfloop query="qry">
6:     ... use data from qry
7: </cfloop>

If a breakpoint was on line 6 we could use a hitcount of 15 and a condition of “qry.last_name eq ‘Smith'”, shown here:

This would stop the page on the 15th row that had the last_name field equal to “Smith”

Read more about Hitcounts

Conclusion

These two features will cut your debugging time down by letting FusionDebug work for you, evaluating conditions that would otherwise need to carried out by yourself, watching the Variables or Expressions view for changes. Most modern debuggers support Conditional Breakpoints and Hitcounts because as applications become more complex, debugging them becomes more complex and in response debuggers must relieve some of this complexity. These two features and countless others do just that.

Other Articles You Might Be Interested In

FusionDebug: Feature Focus – Auto-step

Useful Links

Download FusionDebug 3.0.1 (free trial version available)
FusionDebug Feature Focus