[ http://issues.apache.org/jira/browse/LUCENENET-11?page=comments#action_12444975 ] Joe Shaw commented on LUCENENET-11: -----------------------------------
I think this patch is a decent first step, but I don't think it should go in as-is. It's not clear to me in the Analyzer part of the patch that it would work (but JavaCC code is really ugly). This is because the codepaths that depend on the exception being thrown in StandardTokenizerTokenManager aren't changed to handle with the change in return values from ReadChar(). I also don't think that the changes made to ReadChar() and Refill() make it obvious what the behavior is, and I would recommend a different approach: Change the Refill() method to return a boolean value and instead of throwing an exception, return false in the EOF case and true in the normal case. That return code would have to be checked in ReadChar() and passed out to its callers, which would also have to be changed to handle a new value. It's not clear to me why the changes to FieldInfos.cs exist in this patch at all. I didn't really look at the QueryParser side of things (as I don't use that class myself) but it looks like the same thing there, but in that code the ReadChar() return values are handled, but the (now unnecessary) try/catch statements still remain. > Avoiding non necessary exceptions > --------------------------------- > > Key: LUCENENET-11 > URL: http://issues.apache.org/jira/browse/LUCENENET-11 > Project: Lucene.Net > Issue Type: Improvement > Reporter: Fabio Buscaroli > Attachments: lucene-net-exception.patch, patch.zip, patch2.zip > > > As already said in previous issues, there are few exceptions that are raised > for no reason (apparently). > I updated FastCharStream, QueryParserTokenManager, FieldInfos to avoid these > kind of exception. > - FastCharStream.ReadChar() returns '\0' if we are trying to read byond the > end of the stream. > - Updated QueryParserTokenManager to support the previous fix > - Update FieldInfos.FieldName. No more reading take place if fieldNumber is > -1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
