lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joe Shaw (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENENET-11) Avoiding non necessary exceptions
Date Thu, 26 Oct 2006 20:02:29 GMT
    [ 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

        

Mime
View raw message