lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christoph Goller <>
Subject Re: Why does BooleanQuery$TooManyClauses extend RuntimeException?
Date Thu, 27 Nov 2003 11:19:29 GMT
I agree with Scott. TooManyClausesException is something a developer has to
reckon with. It has to be handled somehow by every implementation. Usually
I see Runtime exceptions as a hint that there is something wrong with the
implementation. However, a TooManyClausesException is a hint that the user
is trying to do something very stupid or practically impossible. Every
implementation should forward this hint somehow to the user. So evern if
it breaks a lot of applications, TooManyClausesException should be a a new kind
of checked exception. This way it enforces all applications to deal with
this case somehow.


Scott ganyo schrieb:
> 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...)
> Scott
> On Nov 26, 2003, at 5:08 PM, Doug Cutting wrote:
>> Scott ganyo wrote:
>>> I have always been rather troubled by this Exception.  The truth is 
>>> that by imposing a limitation where there was none before, this 
>>> change is already an incompatible change to the existing API.  Hiding 
>>> the fact that the original contract has been broken by using a 
>>> RuntimeException to slip past the compiler seems rather wrong to me.  
>>> At least if the Exception was explicit, users could choose to address 
>>> it or ignore it immediately when they compile... rather than being 
>>> bit by it inadvertently at runtime.
>> So what do you propose?
>> Doug
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message