[concurrency-interest] Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated]
gregg at cytetech.com
Sat Dec 25 11:58:10 EST 2010
On 12/22/2010 10:49 AM, Rémi Forax wrote:
> 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.
So the decision about FINE vs WARNING would be part of what to consider. If the
program is already misbehaving because the 'null' is not a an acceptable
situation, then it seems like the logging would be useful to discover this.
Having the problem at WARNING makes it more visible, but can also be turned off
by the reconfiguration of that Logger instance's level.
I use a LogManager which is a Jini service instance (http://logman.dev.java.net)
on my JVMs so that I can connect remotely, watch the logging that I want, and
adjust levels at runtime to make things come and go as I am watching over long
running processes. I believe JMX can also be used to adjust levels.
For me, adjusting logging levels is a regular thing I do. In the current state
of affairs in Java, because NPE is a runtime exception, it is something that
should be caught by a guard catch on any thread whose existence is mandatory in
a JVM. So just rethrowing it might be the thing to do if logging seems like
such a bad thing (TM).
More information about the Concurrency-interest