Benson Margulies created LUCENE-5405: ----------------------------------------
Summary: 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org