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 crash. Thank you for your insight! -Tom --- Erik Hatcher <[EMAIL PROTECTED]> 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: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
