[concurrency-interest] Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated]
forax at univ-mlv.fr
Wed Dec 22 08:49:41 PST 2010
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
>>> with the next element? Clearly if contains() throws and Exception then
>>> 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.
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
More information about the core-libs-dev