lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <e...@ehatchersolutions.com>
Subject Re: VOTE: BooleanQuery$TooManyClauses
Date Tue, 02 Dec 2003 15:06:30 GMT
On Tuesday, December 2, 2003, at 07:43  AM, Otis Gospodnetic wrote:
> I'm for leaving it as it was before this exception was wrapped in
> ParseError/Exception.  This seemed to work well for a long time, as we
> didn't hear anyone complain about it until recently one person asked
> why this exception is not wrapped in ParseError/Exception.

But, the ParseException thing is only one minor area where this could 
happen.  As Doug has said, the TooManyClauses exception would more 
likely be thrown from IndexSearcher.search.

> If this is not an option, then I am in favour of leaving it as it is
> currently in CVS (wrapped in ParseError/Exception).
> (What bothers me about this approach is not the wrapping part, but
> wrapping in something called _Parse_....  I'd be happier if we used
> something more generic, from which one can optionally getCause() or
> some such.)

Like I've said, though, I view it as a "parse" exception because it is 
something the user entered that is not usable.  I understand your 
naming concern here, but having a Lucene runtime exception bubble out 
of the parse method seems mighty rude to me.  If I was implementing a 
system using QueryParser and I knew of that, I'd just implement two 
catch statements around QueryParser.parse and catch it and deal with it 
exactly as I would a ParseException - present a friendly message to the 
user and say "oops, try again".

I cannot imagine anyone would deal with the exceptions differently from 
one another.  Would you?

	Erik


---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org


Mime
View raw message