lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christoph Goller <gol...@detego-software.de>
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.

Christoph

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: 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


Mime
View raw message