Please be advised that this website is now read-only and will be shut down soon.
      Please use, going forward.
More...If you are searching in Tracker for old issues created through bugbase, you can search by the <project_key>-<old bugbase number>.
<project_key> is mapped as:
ColdFusion         : CF     
ColdFusion Builder : CFB    
Framemaker         : FRMAKER
RoboHelp           : RH     
Adobe AIR          : AIR    
Adobe Flash Player : FP     

ColdFusion 9.0.1  -  Bug 3364510

Created on Tuesday, November 13, 2012

Login for more options


CFPARAM functionality missing from param


Problem Description:
With <cfparam> one can do this:

<cfparam name="variables.myRequiredVariable">

This will cause an exception to be raised if variables.myRequiredVariable does not exist. The equivalent functionality for param would be this:

param name="variables.myRequiredVariable";

This however does not work: no exception is raised, and the code continues to run.

Steps to Reproduce:
See above

Actual Result:
See above

Expected Result:
See above

Any Workarounds:
Use structKeyExists() and a throw(), but this is less than ideal.

Test Configuration

My Hardware and Environment details:

App Language(s) English
OS Language(s) English
Platform(s) Win XP All

Notes (11)

  • Suchika Singh

    5:09:48 AM GMT+00:00 Dec 3, 2013

    added test case: qa\cf\regression\coretests\coldfusion\tags\variable-manipulation\cfparam\param\bug3364510.cfm

  • Chandan .

    9:26:09 AM GMT+00:00 Nov 4, 2013

    With returntype being optional, type 1 will always fall under type 2. Whole purpose of adding type 1 was to give a shorthand notation for common usage of param i.e. providing name, default and return type. More than one key=value pair will anyways be treated as type 2.

    And also name is a mandatory field for cfparam. So this fix solves all the cases except when variable's name is name (would need to use type 2 syntax). Marking "name" as special key removes this ambiguity.

  • Adam Cameron

    9:10:47 AM GMT+00:00 Nov 4, 2013

    I think rather than building in "special cases", you should simply check to see whether it fits the attribute="value" style syntax (type 2) first. <cfparam> (and accordingly param) has a closed subset of value attribute combinations, so this is a closed loop as far as possibilities go.

    Then IFF no sense can be made that way, fall back to type 2 syntax.

    Don't hard-code exceptions into your code. That'd be a bad approach.


  • Chandan .

    7:40:20 AM GMT+00:00 Nov 4, 2013

    There are two constructs for param in script syntax
    param [type] varname[= default];
    param [key1=value1];
    param name = "varname";
    falls under type 1 as well. So this got treated as name="name" and default="varname"
    As a fix we would treat this as special case (with name as key and no return type) and would fall to type 2 (which is the tag's behavior)

  • Carl Von Stetten

    8:02:18 PM GMT+00:00 Oct 31, 2013

    Ben Nadel explored this further and has some additional code samples to test against:

  • Adam Cameron

    2:31:21 PM GMT+00:00 Oct 29, 2013

    Thanks Carl. Thinking about it, I'd also quite like to know how Chandan conclude this WASN'T a bug. What exactly did you test? Not the code in the ticket.


  • Carl Von Stetten

    2:24:14 PM GMT+00:00 Oct 29, 2013

    I verified the same problem exists in 9.0.2 (checked it on However, Railo does correctly throw an exception with both <cfparam> and param. This is definitely a bug!

  • Adam Cameron

    2:00:56 PM GMT+00:00 Oct 29, 2013

    Chandan, how did you conclude this is "not a bug" before you even understood what the issue was? This seems a bit premature, don't you think?


  • Carl Von Stetten

    6:47:19 PM GMT+00:00 Oct 28, 2013

    Not sure what CFCLIENT has to do with anything...

  • Adam Cameron

    9:30:52 AM GMT+00:00 Oct 28, 2013

    It's broken. Like I said.

  • Chandan .

    8:48:05 AM GMT+00:00 Oct 28, 2013

    Works fine with and w/o cfclient. Can you please reverify.

Duplicate ID
Reported By Adam Cameron


State Closed
Status Fixed


Priority 3-High
Frequency Most users will encounter
Failure Type Incorrectly Functioning
Product Area Language


Found In Build 9.0.1
Fixed In Build 286560

Attachments (0)

No Files Attached

Votes (1)

  • Carl Von Stetten

    8:03:42 PM GMT+00:00 Oct 31, 2013

    Param and CFPARAM should behave identically.

Your session has expired! Click to login
Current form data will be preserved