[
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
