Probably bug with arraySwap()

Skip to first unread message

Adam Cameron

Aug 23, 2012, 6:57:34 PM8/23/12
Hey, is this a bug or intended behaviour:

a = ["tahi", "toru", "rua", "wha"];
a = [];
a[1] = "tahi";
a[3] = "rua";
a[4] = "wha";


arraySwap(a, 2, 3);

Railo breaks on the second swap, with:

Railo Error (expression)
Messagecan't swap values of array
DetailElement at position [2] doesn't exist in array

CF manages this all right, so I'd've thought Railo would / ought to as well.  If one can have empty array elements, array functions should be able to cope with them, yes?


Gert Franz

Aug 24, 2012, 6:46:27 AM8/24/12

Actually I think CF is doing it wrong here since according to your code there is NO element with the index 2. So how to swap a non existing element with an existing one?


Greetings from Switzerland

Gert Franz


Railo Technologies      Professional Open Source

skype: gert.franz

+41 76 5680 231 

Adam Cameron

Aug 24, 2012, 8:36:25 AM8/24/12
Hi Gert, thanks for replying here.

I dunno that I agree with your assertion there: there is an element at index position 2, it's just null.

This can be borne out by looking at the underlying Vector, and having a poke around:

    a = arrayNew(1);

    a[1] = "tahi";
    a[3] = "rua";
    a[5] = "rima";
    a[7] = "whitu";
    arrayDeleteAt(a, 7);    // 6th / last element is empty

    v = createObject("java", "java.util.Vector").init(a);
    arrayLen(a): #arrayLen(a)#<br />    <!--- this outputs "6" because there IS an element at index point 6 --->
    v.size(): #v.size()#<br />    <!--- this outputs "6" because there IS an element at index point 6 --->

    <cfset e = v.elementAt(1)>    <!---ie: the SECOND element.  This doesn't error because there IS a second element--->
    <!---and, yeah, I get that if I go a[2] I get an error.  I think THIS is the incorrect behaviour in all this --->

    isDefined(): #isDefined("variables.e")#<br /><!---"not defined"... as we know this is how CF deals with NULL --->
    structKeyExists(): #structKeyExists(variables, "e")#<br /><!--- ditto --->

        <cfset e = v.elementAt(6)><!--- (bear in mind that's the SEVENTH element... this is a Java method, so the indexes are zero-based) ie: def doesn't exist in the Vector, so demonstrates what happens when we access the element at an index that doesn't exist. Because the behaviour here is different from when we accessed the second element, it further proves that there IS a second element --->
        <!---this has errored now, so the next coupla lines don't run --->
        isDefined(): #isDefined("variables.e")#<br />
        structKeyExists(): #structKeyExists(variables, "e")#<br />
            <cfdump var="#cfcatch#"><!--- "java.lang.ArrayIndexOutOfBoundsException: 6 >= 6 at java.util.Vector.elementAt(" --->

    toString(): #a.toString()#<br /> <!---shows the nulls --->
    serializeJson(a): #serializeJson(a)#<br /> <!---shows the nulls --->
    <cfdump var="#variables#"><!--- shows the nulls (somewhat inelegantly) --->

So if I want to swap index position 2 (null) & 3 (rua), then that's exactly what I do: put a null in a[3], and put a "rua" into a[2] (obviously one of those is going to go into a temporary variable during the swap, but you get / already knew the idea).



Michael Offner

Aug 27, 2012, 5:09:36 AM8/27/12
i think it is not possible to say what is right and wrong here, in
CFML null does not exists, but behind the curtain it exists ;-) i can
even give you a example where a struct key with null value can be
accessed with regular cfml code.

<cffunction name="test">
<cfargument name="arg1" required="no">

<cfdump var="#arguments#">
<cfdump var="#arguments['arg1']#">
<cfdump var="#arguments.arg1#">
<cfset test()>

if you run this code you will see that there is a value in the
argument scope with the key "arg1" and the value null.
even the value is null the second dump works in this case and outputs
"null" in Railo and ACF, the crazy thing is that the third dump breaks
in ACF with a "Element ARG1 is undefined in ARGUMENTS" exception, in
railo also the 3th dump works, for one simple reason, we will never
handle dot notation and bracket notation in a different way.

you see the answer is not so simple and clear here, simply because
CFML is not consistent in this behavior. we will adapt the ACF
behavior in this case, because (i think) it does not break existing
Railo Code.


2012/8/24, Adam Cameron <>:
> Hi Gert, thanks for replying here.
> I dunno that I agree with your assertion there: there *is *an element at

Michael Offner CTO Railo Technologies GmbH

Michael Offner

Aug 27, 2012, 5:10:31 AM8/27/12
i forgot one thing, can you please raise a ticket for this

tnx micha

2012/8/27, Michael Offner <>:

Adam Cameron

Aug 27, 2012, 6:01:46 AM8/27/12
Thanks for the feedback micha.

Bug raised as RAILO-2048.

Reply all
Reply to author
0 new messages