Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated]

[Rémi Forax]

On 12/22/2010 04:10 PM, Chris Hegarty wrote:
> On 12/22/10 03:07 PM, Rémi Forax wrote:
>> Hi Chris,
>>
>> On 12/22/2010 02:45 PM, Chris Hegarty wrote:
>>> Mike,
>>>
>>> On 12/21/10 09:38 PM, Mike Duigou wrote:
>>>> Thanks. That's an important clarification to include. Here's the
>>>> revised text:
>>>>
>>>> *
>>>> *<p>Care must also be exercised when using collections that do not
>>>> permit
>>>> * calling the {@code contains} method with a {@code null} value. If
>>>> either
>>>> * collection does not permit {@code contains(null)} then both
>>>> collections
>>>> * must not contain {@code null} values.
>>>> *
>>>>
>>>> and the @throws text:
>>>>
>>>> * @throws NullPointerException if either collection is {@code 
>>>> null}. May
>>>> * also be thrown if one collection contains a {@code null} value 
>>>> and the
>>>> * other collection does not permit {@code contains(null)}.
>>>
>>> My concern with this revised wording is that you are now specifying
>>> that the implementation must use contains() ( and not be implemented
>>> using a different strategy ). I guess an alternative implementation is
>>> unlikely, but this does appear overly restricting.
>>>
>>> I wonder if its really necessary to add text to the NPE. A cautionary
>>> note may be sufficient. We could also throw ClassCastException, but
>>> there is no mention of it in the spec.
>>>
>>> Sorry for being a pain about this, I'm just concerned with adding
>>> overly restricting spec.
>>>
>>> Have we thought about catching/swallowing these exceptions?
>>
>> What do you want to do in the catch block ?
>
> Would it make sense to simply swallow the exception ( do nothing ) and 
> continue with the next element? Clearly if contains() throws and 
> Exception then the collection does not contain the given element?

I see,
but the same argument can be applied to contains() i.e why doesn't it 
return false instead of throwing a NPE or a CCE ?

>
> -Chris.

Rémi