RFR: JDK-8114832 it.next on ArrayList throws wrong type of Exception after remove(-1)

[Martin Buchholz]

On Mon, Jul 27, 2015 at 1:19 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

>
> My guiding principle here was that argument validation should not result
> in side-effects. Thus the state of a collection should remain unchanged if
> an exception is thrown due to an invalid argument of an operation.
>
>
That is indeed a good principle.  All or nothing!

But in the case of modCount, one might consider it to record both actual
and attempted modifications.
I would be OK if we decided to make this consistent across all JDK
implementations.  Currently we don't have any internal policy on this,
although you can read the spec
https://docs.oracle.com/javase/8/docs/api/java/util/AbstractList.html#modCount
as requiring successful, not attempted modifications.


> ArrayList.remove is inconsistent with regards to nearly all the other
> ArrayList methods, add(int, E) and addAll(int, Collection) for an out of
> bounds index, and addAll(Collection ), removeAll, retainAll, removeIf,
> replaceAll and sort for a null argument. It’s not inconsistent with
> ArrayList.removeRange, except for if an invalid range from > t, but is
> inconsistent with AbstractList.removeRange. It’s also inconsistent
> LinkedList and CopyOnWriteArrayList *and* sub-lists of ArrayList and
> AbstractList. And inconsistent more generally for other Collection
> implementations, such as Queue.add/offer/remove implementations that do not
> accept null values.
>
> The behaviour of ArrayList.remove, and also ArrayList.removeRange, are
> outliers [*]. It’s also a rather obscure difference behaviour with likely
> minimal impact if changed (far less so than the change to Arrays.toList) .
>

I agree that if we make a policy decision here, we can change it and the
compatibility impact is minimal.