[ https://issues.apache.org/jira/browse/LUCENE-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875709#comment-13875709 ]
Robert Muir commented on LUCENE-5405: ------------------------------------- This also doesnt even solve your problem, where the exception came from *within the analysis chain*. Analysis stuff (e.g. OffsetAttributeImpl) just has a stream of tokens. it doesnt now about nor even have the concept of fields, and is used in cases outside of that context too (e.g. autosuggest). I do not think it buys anything to try to add such stuff to the analysis chain, as thats completely unrelated to the issue. If there is going to be any context added to exceptions, it should be done by the consumer of such streams. > 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