[
https://issues.apache.org/jira/browse/SOLR-9878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15765346#comment-15765346
]
ASF subversion and git services commented on SOLR-9878:
-------------------------------------------------------
Commit 1e22dd25bf20844c71648c39028c48d2a9aa4e58 in lucene-solr's branch
refs/heads/branch_6x from [~mkhludnev]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1e22dd2 ]
SOLR-9878: fix ReversedWildcardFilterFactory caching in query parser
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
