[
https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875712#comment-13875712
]
Robert Muir commented on LUCENE-5405:
-------------------------------------
I don't think we should change the design of the analysis stuff (adding field
names to it, add new classes or new method signatures) to support the buggy
case.
To me the question is if there should be some change to DocInverterPerField or
not: and to me thats the only place where we might change anything, because
indexwriter "iterates" field names for you and its true you dont have an easy
way (to my knowledge) to figure out which one it was "on" when it hit an issue.
Otherwise, consumers such as queryparsers etc can deal with this themselves, if
they want to add try/catch, so be it. I am sure that stuff e.g. solr is already
wrapping the exceptions there in useless SolrExceptions today.
> Exception strategy for analysis improved
> ----------------------------------------
>
> Key: LUCENE-5405
> URL: https://issues.apache.org/jira/browse/LUCENE-5405
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Benson Margulies
>
> SOLR-5623 included some conversation about the dilemmas of exception
> management and reporting in the analysis chain. Here is a 5.0 proposal:
> TokenStream.reset and TokenStream.incrementToken (and perhaps the rest)
> should have a new, checked, exception in their signatures: call it
> AnalysisError if you like. Unlike IOException, it will have a full set of
> constructors, including the constructors that can wrap a 'cause'. Its
> constructors will accept a field name.
> TokenStream will have a fieldName field, accepted in a constructor argument.
> (OK, this might a bit authoritarian.)
> TokenStream will have:
> protected void throwAnalysisException(String explanation, Throwable cause) {
> throw new AnalysisException(fieldName, explanation, cause);
> }
> Implementors of analysis will be thus encouraged to write things like:
> try {
> doSomething();
> } catch (IOExceptionOrWhatever e) {
> throwAnalysisException("Some Explanation", e);
> }
> Then, situations like Solr can diagnose the field name.
> Note that no information is lost here, due to the use of exception wrapping.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
