lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott ganyo <>
Subject Re: Why does BooleanQuery$TooManyClauses extend RuntimeException?
Date Thu, 27 Nov 2003 16:57:45 GMT
Yes, I understand that this is dramatic.  Adding this as a checked 
exception makes this an incompatible change with Lucene 1.2.  And 
normally I would argue against doing this without good reason.  Let's 
face it, though:  The change that causes the TooManyClauses is also 
incompatible with Lucene 1.2!

So my position is simply this:  Either we have an incompatible change 
or we don't.  Period.

Let's either get rid of the incompatibility itself (i.e. remove the max 
number of clauses check completely or increase the limit to 
MAX_INTEGER) or let's own up to the making this incompatible change and 
make TooManyClauses a checked Exception.


On Nov 27, 2003, at 5:32 AM, Erik Hatcher wrote:

> On Wednesday, November 26, 2003, at 10:15  PM, Scott ganyo wrote:
>> Sorry, I should have been more clear.  I really believe that the best 
>> option is to have TooManyClauses Exception be changed to subclass 
>> Exception directly.  This makes it explicit that prior assumptions 
>> about the operation of the BooleanQuery are no longer valid and would 
>> force developers to recognize that fact when they compile against the 
>> new version of the library.  Yes, I understand that this may be a 
>> PITA (pain-in-the-...) to some folks but again, I'd rather have a 
>> concrete, immediate compile failure rather than a hidden runtime 
>> failure.  (The same kind of reason I prefer using a strongly-typed 
>> language...)
> But, as Doug mentioned, the effect of doing so is quite dramatic.  All 
> of Lucene's operations throw an IOException currently - so adding a 
> checked exception would require it be dealt with in a vastly different 
> way somehow.
> So, with that in mind - do you still propose making it a checked 
> exception?
> In the long run (Lucene 2.0?!), perhaps a LuceneException could be 
> thrown from all operations which could wrap nested IOExceptions and 
> any other checked exceptions that might come along in the future.  But 
> for a 1.3 release, I think running with what is there is best.
> 	Erik
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
The reasonable man adapts himself to the world; the unreasonable one 
persists in trying to adapt the world to himself. Therefore all 
progress depends on the unreasonable man. - George Bernard Shaw

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message