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

[Rémi Forax]

On 12/22/2010 04:55 PM, Chris Hegarty wrote:
> On 12/22/10 03:34 PM, Gregg Wonderly wrote:
>> On 12/22/2010 9:10 AM, Chris Hegarty wrote:
>>> On 12/22/10 03:07 PM, Rémi Forax wrote:
>>>> On 12/22/2010 02:45 PM, Chris Hegarty wrote:
>>>>> 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?
>>
>> It seems that Logger use here might be useful. A FINE level log of the
>> stack trace would allow the user to discover why the failure/success
>> return was not as they expected. From some perspectives, I'd be tempted
>> to log at WARNING for myself as this does represent an unexpected, yet
>> non-fatal condition in the software.
>
> Yes, this is a good proposal. I guess we need to establish whether we 
> consider passing these "incompatible" collections a programmer error 
> or not. I was just trying to ensure that we had considered all options.
>
> -Chris.

The main problem with logging is that you may see a lot of records
if the application compares huge of collections of turtles and nipples 
(i.e collections of incompatible type)
Moreover if a code relies on catching a CCE in that case, if we log or 
silently ignore the CCE,
the performance will drop.

>
>>
>> Gregg Wonderly

Rémi