[ 
https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875711#comment-13875711
 ] 

Benson Margulies commented on LUCENE-5405:
------------------------------------------

Hmm, well, backing up. In the other discussion, you and others seemed very 
unhappy with schemes of the form:

    throw new SomeException("Some local explanation", someExceptionObject);

Based on your most recent remark, I don't see any other way to get around this; 
my idea about storing field names is stupid, since the chains are reusable. So, 
either this sort of wrapping is tolerable or not. If tolerable, I'll rewrite 
this JIRA, else I'll close it.


> 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]

Reply via email to