You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Doug Cutting <cu...@lucene.com> on 2003/12/01 19:02:10 UTC
VOTE: BooleanQuery$TooManyClauses
Wow! What a tempest in a teapot this one has become!
Here are the options as I see them.
1. Change TooManyClauses to directly extend Exception.
This is unacceptable. We cannot force all developers to change their
code for a point release.
2. Disable the feature by default.
This would be a shame. This feature saves folks who were getting
mysterious (unchecked) out-of-memory errors, instead giving them an
explicable (if still unchecked) error, a bit sooner, one they can catch
and deal with. Practically, it only affects applications which permit
rampant use of wildcards, a questionable practice anyway.
3. Change TooManyClauses to extend IOException.
IOException is already thrown by all of the search methods in question,
so that applications must already deal with this. This is not ideal, as
the condition doesn't actually involve i/o, but IOException is already
effectively used as LuceneException. (In a 2.0 release we should, as
Erik suggests, rationalize Lucene's exceptions.)
Thus I propose to implement (3). Votes?
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
Re: VOTE: BooleanQuery$TooManyClauses
Posted by Scott ganyo <sc...@ganyo.com>.
My vote is with option 3.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
Re: VOTE: BooleanQuery$TooManyClauses
Posted by Dmitry Serebrennikov <dm...@earthlink.net>.
I haven't been following this thread closely because I don't use the
wildcard queries, which I think are the main source of this exception,
but I agree with Doug's choice below - option 3 at least until 2.0. This
is assuming that option 0 - do nothing, is not an option at this point.
Dmitry.
Doug Cutting wrote:
> Wow! What a tempest in a teapot this one has become!
>
> Here are the options as I see them.
>
> 1. Change TooManyClauses to directly extend Exception.
>
> This is unacceptable. We cannot force all developers to change their
> code for a point release.
>
> 2. Disable the feature by default.
>
> This would be a shame. This feature saves folks who were getting
> mysterious (unchecked) out-of-memory errors, instead giving them an
> explicable (if still unchecked) error, a bit sooner, one they can
> catch and deal with. Practically, it only affects applications which
> permit rampant use of wildcards, a questionable practice anyway.
>
> 3. Change TooManyClauses to extend IOException.
>
> IOException is already thrown by all of the search methods in
> question, so that applications must already deal with this. This is
> not ideal, as the condition doesn't actually involve i/o, but
> IOException is already effectively used as LuceneException. (In a 2.0
> release we should, as Erik suggests, rationalize Lucene's exceptions.)
>
> Thus I propose to implement (3). Votes?
>
> Doug
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
Re: VOTE: BooleanQuery$TooManyClauses
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Monday, December 1, 2003, at 01:02 PM, Doug Cutting wrote:
> Wow! What a tempest in a teapot this one has become!
Oops... sorry!
> Here are the options as I see them.
>
> 3. Change TooManyClauses to extend IOException.
>
> IOException is already thrown by all of the search methods in
> question, so that applications must already deal with this. This is
> not ideal, as the condition doesn't actually involve i/o, but
> IOException is already effectively used as LuceneException. (In a 2.0
> release we should, as Erik suggests, rationalize Lucene's exceptions.)
>
> Thus I propose to implement (3). Votes?
What about leave it as-is? My only beef was with QueryParser throwing
something other than ParseException. I personally haven't run into
this issue.
I'm find with option 3, if a change must be made.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
Re: VOTE: BooleanQuery$TooManyClauses
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
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
Re: VOTE: BooleanQuery$TooManyClauses
Posted by Otis Gospodnetic <ot...@yahoo.com>.
I'm for the option that is not listed below. :)
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.
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.)
If that is not an option, then I am for option 3 with a strong emphasis
on changing this not to be a subclass of IOException for the next major
release.
Otis
--- Doug Cutting <cu...@lucene.com> wrote:
> Wow! What a tempest in a teapot this one has become!
>
> Here are the options as I see them.
>
> 1. Change TooManyClauses to directly extend Exception.
>
> This is unacceptable. We cannot force all developers to change their
>
> code for a point release.
>
> 2. Disable the feature by default.
>
> This would be a shame. This feature saves folks who were getting
> mysterious (unchecked) out-of-memory errors, instead giving them an
> explicable (if still unchecked) error, a bit sooner, one they can
> catch
> and deal with. Practically, it only affects applications which
> permit
> rampant use of wildcards, a questionable practice anyway.
>
> 3. Change TooManyClauses to extend IOException.
>
> IOException is already thrown by all of the search methods in
> question,
> so that applications must already deal with this. This is not ideal,
> as
> the condition doesn't actually involve i/o, but IOException is
> already
> effectively used as LuceneException. (In a 2.0 release we should, as
>
> Erik suggests, rationalize Lucene's exceptions.)
>
> Thus I propose to implement (3). Votes?
>
> Doug
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org