[jira] [Commented] (SOLR-9878) Code smell in if statement

["Tomás Fernández Löbbe (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-9878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15762753#comment-15762753 ] 

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

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

> Code smell in if statement
> --------------------------
>
>                 Key: SOLR-9878
>                 URL: https://issues.apache.org/jira/browse/SOLR-9878
>             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
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org