[
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.
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.
> 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.
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
