Misleading error message when array index out of bound
I'm doing some work with arrays. At one point, I got this message
Error at char 0 in expression in xsl:variable/@select on line 336 column 64 of tablecals.xsl: FOAY0001 Requested 1, actual size 1
That puzzled me. It took me a long time to add an xsl:message and work out that I was actually asking for item 2 in this array of length 1.
I tried to reproduce this with a very simple test and got a different message
Error FOAY0001 while evaluating xsl:message at line 14 of file:/tmp/out.xsl: Array index (2) out of range (1 to 1)
At a guess, I'd say whatever part of the code generates the former message is reporting the 0-based Java index and not the 1-based XSLT index.
In any event, if you need code to reproduce this, I'll keep a snapshot around.
#1 Updated by Michael Kay over 1 year ago
Noted. It seems the "good" message is coming when we do
array:get() on a
SimpleArrayItem, and the "bad" message is coming when we do
put()) on an
ImmutableArrayItem. These are just two different internal implementations of XDM arrays; the
SimpleArrayItem is used for arrays that have not undergone any incremental modifications, while the
ImmutableArrayItem is used when there have been such modifications or where we think they are likely.
#2 Updated by Michael Kay over 1 year ago
For 10.0 I have changed the approach for bounds-checking, which is currently very haphazard.
(a) the code for the specific array function (e.g
array:put()) checks the subscript before calling underlying methods on the
(b) the XDM array object's methods (get, put, remove) -- which use zero-based subscripts -- are declared to throw
IndexOutOfBoundsException if the subscript is out of range; but this won't happen for a direct call from a function such as array:get(), because the value will already have been checked
(c) the responsibility for checking (b) rests with the implementation class, e.g.
(d) we don't attempt to catch the
IndexOutOfBoundsException because it should never happen.
For 9.9 I will make a more modest change that only affects ImmutableArrayItem.get().
Please register to edit this issue