lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tomcat Programmer <>
Subject Re: QueryParser Rules article (Erik Hatcher)
Date Thu, 13 Nov 2003 23:46:12 GMT

Hi Eric, 

Thanks for the replies, and your consideration on this
problem.  In my case, I use the non-static method
because I want to set some properties (most
importantly the default operator to AND) for the query
parser. Looking at the code snip provided, I guess the
only thing the query parser will do is trap the
TokenMgrError and then throw it as a ParseException. I
think thats a good start, and it will help me for sure
since I am really only using the query parser and so
far have not needed to write anything custom yet to
work with the analyzer or its lexing.

Hopefully the dev group will consider refactoring the
code so that when its doing the lexing it will throw
TokenMgrException's instead of TokenMgrError's. 
Throwing Errors should be reserved for only the most
nasty of conditions. The compiler will force you to
catch or throw Exceptions, but not Errors. Thus, the
developer will never see it coming when their
application comes to a grinding halt. 

In the web apps world, there is already a rich
exception handling system set up by the container. If
an Error is thrown, it will stop a servlet dead in its
tracks and will never get to your exception processing
system.  Early on when using Lucene, I had dealt with
it by wrapping my Lucene code in an envelope to trap
the errors so that it does not cause the servlet to

Thank you for your insight! 


--- Erik Hatcher <> wrote:
> On Wednesday, November 12, 2003, at 11:52  PM,
> Tomcat Programmer wrote:
> > When using the QueryParser class, the parse method
> > will throw a TokenMgrError when there is a syntax
> > error even as simple as a missing quote at the end
> of
> > a phrase query. According to the javadoc, you
> should
> > never see this class derived from Error being
> thrown
> > (oops?)
> After looking at it some more, I decided that only
> ParseException 
> should come out of either of the parse methods and
> committed the 
> change.  I'm not sure why TokenMgrError was ever
> publicly exposed from 
> the instance parse method.  If there is a good
> reason we can change it 
> back, but I don't see any reason.
> 	Erik
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message