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

[Chris Hegarty]

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?

-Chris.

>
>>
>> -Chris.
>
>
> Rémi
>