Mauro, > On 6. 2. 2025, at 18:24, Mauro Molinari <mauro...@tiscali.it> wrote: > Isn't the contract of List requiring to throw an IndexOutOfBoundsException > though, in case index is invalid?
Far as the API contract goes, I guess it would be probably an undocumented behaviour (which actually makes sense, allowing each class to behave as it[s creator] wished), given an index value (-self.size() <= idx < self.size()) <https://docs.groovy-lang.org/latest/html/groovy-jdk/java/lang/Iterable.html#getAt(int)> neither Collection <https://docs.groovy-lang.org/latest/html/groovy-jdk/java/util/Collection.html#getAt(java.lang.String)> nor List <https://docs.groovy-lang.org/latest/html/groovy-jdk/java/util/List.html#getAt(int)> itself seem to add anything more of importance to that. Note the Java documentation, well, for one, is not that relevant for Groovy ;), but far as you want to go with it, it knows neither getAt nor indices of course; and for get, its contract holds: === groovy:000> a=[1] ===> [1] groovy:000> a[1] ===> null groovy:000> a.getAt(1) ===> null groovy:000> a.get(1) ERROR java.lang.IndexOutOfBoundsException: Index: 1, Size: 1 groovy:000> === In practice, List indices >= size always returned null and never threw far as I can recall. All the best, OC > 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 <mailto:o...@ocs.cz>> >>> Sent: Thursday, February 6, 2025 10:11 AM >>> To: dev@groovy.apache.org <mailto:dev@groovy.apache.org> >>> <dev@groovy.apache.org <mailto: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 >>> <https://urldefense.com/v3/__https://docs.groovy-lang.org/latest/html/documentation/*_working_with_arrays__;Iw!!GFN0sa3rsbfR8OLyAw!ezrONlzs3yG6lC6cFTDF2ASi61brEmoT2ix7QriL2Tg7vhHIhMXTwpPoYFbS77qNBafdycrQlnIZgRDxsA$>. >>> >>> 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 >>> <mailto: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 >>> <mailto: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. >> > >
