lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tomás Fernández Löbbe (JIRA) <>
Subject [jira] [Commented] (SOLR-9878) Code smell in if statement
Date Tue, 20 Dec 2016 00:29:58 GMT


Tomás Fernández Löbbe commented on SOLR-9878:

Yes, that doesn't look right. Also, {{leadingWildcards}} is defined as:
private Map<FieldType, ReversedWildcardFilterFactory> leadingWildcards;
there is no way to have a ReversedWildcardFilterFactory as key

> 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
> 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