Isn't the contract of List requiring to throw an IndexOutOfBoundsException
though, in case index is invalid?
Mauro Molinari
mauro...@tiscali.it
In data 6 Febbraio 2025 18:00:36 OCsite <o...@ocs.cz> ha scritto:
Eric,
I know of no oficial documentation explaining this (which does not mean
there's none; perhaps I've just missed it).
Some time ago Paul wrote unofficially that a list can be sort of seen as a
map from indices to values, and as such, it is expected that non-existing
indices return null instead of throwing.
The question is whether the technical background (an array can be hardly
considered a map, after all) or the polymorphic API (whatever it is, we
want that indexing works consistently) should win. Myself I would vote for
the latter, but alas I have no idea of the original intention (but for the
quoted documentation line, which seems rather to support the latter too).
That's why I've asked :)
On the other hand, there's at least one more polymorphic indexing
available, the one with strings; and in there non-existent indices throw
too, quite consistently with arrays.
Thanks and all the best,
OC
On 6. 2. 2025, at 17:27, Milles, Eric (TR Technology) via dev
<dev@groovy.apache.org> wrote:
Is there any explicit statement about how indexing beyond the end of a
collection should work? Does it extend the collection or just return null.
Does a withDefault collection do something different?
In general, arrays and collections should work the same, so the statement
in the working with arrays section is a good one. In the matter of
indexing beyond the end of the array or collection, what is the shared
behavior supposed to be:
return default value for type — aka null for reference and 0/false for
primitives
throw out-of-bounds exception
something else?
From: OCsite <o...@ocs.cz>
Sent: Thursday, February 6, 2025 10:11 AM
To: dev@groovy.apache.org <dev@groovy.apache.org>
Subject: [EXT] Re: a bug or my fault?
External Email: Use caution with links and attachments.
The overall intention is that whether you are using an array or a
collection, the code for working with the aggregate remains the same.
In this particular case alas that good and noble intention does not quite
work, and I wonder whether that is intentional (forgive the pun) or a
mistake to be fixed in future, when there's nothing more pressing to do.
On 6. 2. 2025, at 13:30, Søren Berg Glasius <soe...@glasius.dk> wrote:
You assign 'b' as an Array, and arrays works differently than lists. Arrays
are bound to their length, so 'a[2]' should report out of bounds as it is
not 3 elements long, whereas a list b[2] would report null
IMO it's working as intended.
Den tors. 6. feb. 2025 kl. 10.20 skrev OCsite <o...@ocs.cz>:
Hi there,
is this inconsistence intentional and the proper Groovy behaviour, or is
that a bug and should I add a jira ticket?
Thanks!
===
groovy:000> a=[1,2]
===> [1, 2]
groovy:000> b=a as Object[]
===> [1, 2]
groovy:000> a[2]
===> null
groovy:000> b[2]
ERROR java.lang.ArrayIndexOutOfBoundsException:
Index 2 out of bounds for length 2
groovy:000>
===
--
Med venlig hilsen,
Søren Berg Glasius
Hedevej 1, Gl. Rye, 8680 Ry
Mobile: +45 40 44 91 88
--- Press ESC once to quit - twice to save the changes.
