lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Khludnev (JIRA)" <>
Subject [jira] [Commented] (SOLR-9878) Code smell in if statement
Date Wed, 21 Dec 2016 06:44:58 GMT


Mikhail Khludnev commented on SOLR-9878:

when a fieldType doesn't have RWFF it's cached as null value and isn't checked anymore. I
agree it's not obvious and probably over-engineered, but I decided to fix as is. You can check
the test which demonstrate this invariant. 
Thanks for reporting.    

> Code smell in if statement
> --------------------------
>                 Key: SOLR-9878
>                 URL:
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Jaechang Nam
>            Priority: Trivial
>         Attachments: SOLR-9878.patch
> In recent code snapshot (Github mirror's commit id: c8542b2bd0470af9f8d64bb8133f31828b342604
as today), there is an illogical condition that can be a code smell or a potential bug:
> {code}
> ReversedWildcardFilterFactory fac = leadingWildcards.get(fieldType);
>     if (fac != null || leadingWildcards.containsKey(fac)) {
>       return fac;
>     }
> {code}
> In SOLR-3492, it said there was a fix in SOLR-4093. However, the fix still has an issue
as above: containsKey will always have null in this if statement. The second condition could
be unnecessary. Does leadingWildcards allow a null object as a key? If so, it will return
null that might cause NPE in some other locations.
> Patch could be just like in SOLR-3492?:
> {code}
> if (fac != null)
> {code}

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message