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

[Paul Sandoz]

On 27 Jul 2015, at 20:53, Martin Buchholz <martinrb at google.com> wrote:
> 
> 
> 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.

I just implicitly assumed that was always the case :-) as i assume did many core library implementors.


> 
> 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.


Since there already exists an implicit policy governed by like 99.9% of the existing behaviour i do not see the need to be explicit about that policy for this particular issue, so i suggest we split into two.

Paul.