lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jaechang Nam (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (SOLR-9878) Code smell in if statement
Date Mon, 19 Dec 2016 19:12:58 GMT

     [ https://issues.apache.org/jira/browse/SOLR-9878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jaechang Nam updated SOLR-9878:
-------------------------------
    Description: 
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}

  was:
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 locaions.

Patch could be just like in SOLR-3492?:

{code}
if (fac != null)
{code}


> 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


Mime
View raw message