On Oct 16, 2013, at 1:52 PM, David Holmes <david.hol...@oracle.com> wrote:
>>> Perhaps HashMap's implementations should throw CME?
>>>
>>
>> Perhaps, seems to be going beyond the call of duty. My inclination is not to
>> bother. It becomes most relevant with forEach since the consumer will have
>> side-effects that might make it easier to unintentionally slip in a
>> modification to the map itself.
>
> I think there is a lot to be said for consistency.
Yes, i was proposing to consistently not support it for non-traversal methods
:-)
> At present it seems we don't have a clear idea on how these methods should be
> spec'd or how the implementations should behave.
>
>>> But the possibility of CME has to be allowed for in the spec of the
>>> interfaced methods regardless.
>>>
>>
>> Ideally by not say anything :-) otherwise perhaps a variant of the following:
>
> Not saying anything doesn't permit CME to be thrown.
>
Yeah, it was my poor attempt at a joke wishing CME would go away :-)
>> "If a function value passed to an operation of a non-concurrent map modifies
>> the contents of that map then the result of that operation is undefined. An
>> implementation may throw {@link ConcurrentModificationException} in such
>> cases and if so that behaviour should be documented."
>
> I don't think it is the Java spirit to allow for undefined behaviour.
OK.
> Wouldn't:
>
> @throws CME if the <function> modifies the map and this is detected by the
> implementation
>
> give the same flexibility while not being so obviously flimsy?
Reluctantly yes; i know it's more of a style thing but it is somewhat tiresome
for each and every method receiving a function value to repeat the same thing.
Paul.
> I prefer to see exception info on methods as much as practical - with NPE
> being the obvious exception (no pun intended).
>
