cfparam gotcha.

Today in my general work I found a small gotcha about cfparam that wasn’t apparent to me (note that I work in CF under railo, so not sure of the exact implementation in Adobe’s ColdFusion).

Using the following code:

<cfparam name="URL.test" type="boolean" default=false&>

If you loaded a page with this code in it with the URL params looking like: ?test=tr, you would get an error about type mismatch. Now initially this confused me as I thought that an error like this would have been caught and simply the param fixed to the default value. My eventual solution to this is as follows:

<cftry>
	<cfparam name="URL.test" type="boolean" default=FALSE>
	<cfcatch type="any">
		<cfset URL.test = FALSE>
	</cfcatch>
</cftry>

Hopes this helps someone else as it helped me.

About Simeon Cheeseman

I enjoy a wide variety of computer and board games, have a BSc in Computer Science and have played percussion for 18 years.

Posted on October 31, 2011, in ColdFusion. Bookmark the permalink. 5 Comments.

  1. You may of course have a specific reason, but why not just leave it untyped? I assume that somewhere you are doing something like:

    <cfparam name=”url.test” default=”false” />

    <cfif url.test>
    <!— do something testy —>
    </cfif>

    ACF, OpenBD, & Railo would all interpret the string as boolean in the condition if you did this. If you come from a strictly typed background it is tempting to type everything. I often do just for the sake of code clarity, but sometimes it is nice enjoy the simplicity of a loosely typed language.

  2. oops… for clarity, a couple of points. The dash-dash-dash in the comments appear to have become a solid line, and I forgot to scope the variable name in the cfparam as “url.test”.

  3. Yes that generally was my intention to implement it as you show, I found that it only works as long as you have a well formed URL parameter. Even your case will error if you use a URL like: http://localhost/test.cfm?test=tr

    So really this only matters if you want to catch such an error!

  4. Yeah, you are absolutely right. I clearly had a brainfart posting this. I am neck deep in a Grails project and have clearly gotten too used to being able to treat *anything* as a boolean. In Groovy, essentially everything can be treated as a boolean, and if the value is NULL, it’s false. I have grown very fond of that! Sorry for the static… 🙂

  5. Heh, no worries, thou I would much rather if it worked as you said (and initially I thought it did – hence the post)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: