[groovy-dev] Bug or feature?

[Russel Winder]

I find that:

a = []
a[2]

does not throw IndexOutOfBoundsException and returns null, but:

a = []
a.get(2)

throws IndexOutOfBoundsException. For me this is a failure of The
Principle of Least Surprise. Am I just missing something such that the
behaviour is acceptable and desired?

[Sergei Egorov]

This is a feature. [] are safe and not throwing IOOB

Post by Russel Winder
a = []
a[2]
a = []
a.get(2)
throws IndexOutOfBoundsException. For me this is a failure of The
Principle of Least Surprise. Am I just missing something such that the
behaviour is acceptable and desired?
--
Russel.
=============================================================================
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

[Dinko Srkoč]

Post by Russel Winder
a = []
a[2]
a = []
a.get(2)
throws IndexOutOfBoundsException. For me this is a failure of The
Principle of Least Surprise. Am I just missing something such that the
behaviour is acceptable and desired?

`get` and `getAt` are distinctive methods, one throws IOOB, the other
returns `null` for out of range access. Another difference is in
treating negative indices. `get` comes from Java, `getAt` is, perhaps,
inspired by Ruby's Array access.

The idiomatic positional access is Groovy is via `getAt` method (in
its sugared form). When an effort is made to use non-idiomatic means
(such as Java's `get`), one should probably expect different
behaviour.

Cheers,
Dinko

Post by Russel Winder
--
Russel.
=============================================================================
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Cédric Champeau]

This is actually one of the Groovy features I very much dislike. I
really hate that the subscript operator on a *List* (not an array)
doesn't throw an exception, but transparently grows the list and returns
null. This is really, really annoying to me. It's fun because we talked
this a lot internally, because it was one of the "features" I disabled
in the past, when I wasn't a Groovy committer, because it caused a lot
of idiotic errors at runtime in the context of a rule engine, when a NPE
was thrown, and it was hard to find out that the problem came from a
list that didn't contain enough elements. Let's illustrate this:

|def list = ['a','b','c]||
||// ||50 lines of code||
||def e = list[3] // oh noes||
||// 20 lines of code||
||e.toUpperCase() // boom!|

Now the error was at line "def e", not the call to toUpperCase, and you
have *no* way to find this out in a more complex flow. It caused me
hours of debugging so I'm very vocal about this "feature" :)

Post by Dinko Srkoč

Post by Russel Winder
a = []
a[2]
a = []
a.get(2)
throws IndexOutOfBoundsException. For me this is a failure of The
Principle of Least Surprise. Am I just missing something such that the
behaviour is acceptable and desired?

`get` and `getAt` are distinctive methods, one throws IOOB, the other
returns `null` for out of range access. Another difference is in
treating negative indices. `get` comes from Java, `getAt` is, perhaps,
inspired by Ruby's Array access.
The idiomatic positional access is Groovy is via `getAt` method (in
its sugared form). When an effort is made to use non-idiomatic means
(such as Java's `get`), one should probably expect different
behaviour.
Cheers,
Dinko

Post by Russel Winder
--
Russel.
=============================================================================
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

[Dinko Srkoč]

This is actually one of the Groovy features I very much dislike. I really
hate that the subscript operator on a *List* (not an array) doesn't throw an
exception, but transparently grows the list and returns null. This is
really, really annoying to me. It's fun because we talked this a lot
internally, because it was one of the "features" I disabled in the past,
when I wasn't a Groovy committer, because it caused a lot of idiotic errors
at runtime in the context of a rule engine, when a NPE was thrown, and it
was hard to find out that the problem came from a list that didn't contain
def list = ['a','b','c]
// 50 lines of code
def e = list[3] // oh noes
// 20 lines of code
e.toUpperCase() // boom!
Now the error was at line "def e", not the call to toUpperCase, and you have
*no* way to find this out in a more complex flow. It caused me hours of
debugging so I'm very vocal about this "feature" :)

So, you should've used `get`. :-)

Yes, I've been bitten by that too. But somewhere else I relied on that
feature (it saved me initializing a list by hand).

And even `get` won't save you from runtime exceptions, it will just be
easier to debug (sometimes a lot easier).

Cheers,
Dinko

a = []
a[2]
a = []
a.get(2)
throws IndexOutOfBoundsException. For me this is a failure of The
Principle of Least Surprise. Am I just missing something such that the
behaviour is acceptable and desired?
`get` and `getAt` are distinctive methods, one throws IOOB, the other
returns `null` for out of range access. Another difference is in
treating negative indices. `get` comes from Java, `getAt` is, perhaps,
inspired by Ruby's Array access.
The idiomatic positional access is Groovy is via `getAt` method (in
its sugared form). When an effort is made to use non-idiomatic means
(such as Java's `get`), one should probably expect different
behaviour.
Cheers,
Dinko
--
Russel.
=============================================================================
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email
--
Cédric Champeau
SpringSource - Pivotal
http://twitter.com/CedricChampeau
http://melix.github.io/blog
http://spring.io/ http://www.gopivotal.com/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email