Please be advised that this website will become read-only on December 09, 2016 and will be shut down soon after.
      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     
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