[ https://issues.apache.org/jira/browse/SOLR-9878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mikhail Khludnev updated SOLR-9878: ----------------------------------- Attachment: SOLR-9878.patch what about [^SOLR-9878.patch]? this fixes caching of nulls. > 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