Hm, I'm not sure if I like this change. Yes, this change makes it easier to handle TooManyClauses exception, but the cause exception has nothing to do with parsing, and wrapping it in ParseException hides that.
I prefer leaving things like before. Anyone who uses Lucene for serious business should have read the Javadoc for various queries, and not just the QueryParser, so complaining that this is only documented in BooleanQuery javadoc is not a good excuse, IMHO. Furthemore, anyone who uses QueryParser should know that ParseException will be thrown every once in a while, when users enter a query with invalid syntax, and such. Entering a Prefix or Wildcard query that results in more than 1024 BooleanQueries is not the result of invalid query syntax, but indicates a different problem, which those running the Lucene-based application may want to know about and handle differently. What do you think? Otis --- Erik Hatcher <[EMAIL PROTECTED]> wrote: > On Tuesday, November 25, 2003, at 06:50 PM, Jon Pipitone wrote: > > When I switched over to Lucene 1.3 RC2 I found that a user of my > > application could create an unhandled exception, just by entering > in a > > wild card query. (There was a post today about this [1]). > > > > The exception being thrown when a wildcard query causes a > BooleanQuery > > to grow too large, BooleanQuery$TooManyClauses, extends > > RuntimeException. As such, the method throwing it -- > > BooleanQuery.add() -- doesn't need to declare that it throws it, > nor > > if it did would there be any compilation errors if the caller does > not > > catch it. > > > > My application was using QueryParser as before, and there were no > > compile time errors to indicate that I would need to catch this > sort > > of exception. Of course, it is in the javadoc (but of BooleanQuery > > > not QueryParser). > > > > My question is, if throwing BooleanQuery$TooManyClauses is part of > the > > API (which it seems like it is implicitly) then shouldn't it be > > enforced at compile time? What about wrapping this sort of > exception > > in a ParseException so that it can be handled like all other parse > > exceptions? > > I concur and have just modified QueryParser to throw a ParseException > > instead when a TooManyClauses exception is thrown. I checked the > codebase for any other custom Errors/Exceptions and don't see any > others that would be thrown so I think we've got the bases covered in > > QueryParser now. You could still get some other type of > RuntimeException if things went haywire somewhere under the covers, > but > this is a more or less expected exception that makes sense to catch > as > a ParseException for nicer handling by a UI. > > Erik > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
