[ https://issues.apache.org/jira/browse/SOLR-7765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14637291#comment-14637291 ]
Konstantin Gribov commented on SOLR-7765: ----------------------------------------- I understand you point, I write in C time to time. My point is that it leads to inconsistency in code style without any profit (like eliminating error-prone constructs in C). It makes no sense in java, since for types other than boolean it will produce compile-time error (because type incompatibility) and for boolean ifs will look like {{if (val)}} or {{if (!val)}}. It seems that there's no place to make this types of error in java. > TokenizerChain methods may return null depending on how constructor is called > -- causes NPE in luke request handler > ------------------------------------------------------------------------------------------------------------------- > > Key: SOLR-7765 > URL: https://issues.apache.org/jira/browse/SOLR-7765 > Project: Solr > Issue Type: Bug > Affects Versions: 5.2.1 > Reporter: Konstantin Gribov > Assignee: Hoss Man > Priority: Minor > Fix For: 5.3, Trunk > > Attachments: SOLR-7765.patch, SOLR-7765.patch, SOLR-7765.patch > > > {{TokenizerChain}} created using 2-arg constructor has {{null}} in > {{charFilters}}, so {{LukeRequestHandler}} throws NPE on iterating it. > {{TokenizerChain}} constructor's should be hardened to do explicit null > checks, throwing early NPE where appropriate (tokenizer factory), or > initializing internal arrays to have 0 length when optional (factories for > char filters and token filters) -- 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