lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otis Gospodnetic <otis_gospodne...@yahoo.com>
Subject Re: VOTE: BooleanQuery$TooManyClauses
Date Tue, 02 Dec 2003 12:43:15 GMT
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 <cutting@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


Mime
View raw message