[
https://issues.apache.org/jira/browse/SOLR-9878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15766287#comment-15766287
]
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: 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
> 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
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
