From lucene-dev-return-4762-apmail-jakarta-lucene-dev-archive=jakarta.apache.org@jakarta.apache.org Mon Dec 01 23:33:40 2003 Return-Path: Delivered-To: apmail-jakarta-lucene-dev-archive@www.apache.org Received: (qmail 10779 invoked from network); 1 Dec 2003 23:33:40 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 1 Dec 2003 23:33:40 -0000 Received: (qmail 77397 invoked by uid 500); 1 Dec 2003 23:33:24 -0000 Delivered-To: apmail-jakarta-lucene-dev-archive@jakarta.apache.org Received: (qmail 77373 invoked by uid 500); 1 Dec 2003 23:33:24 -0000 Mailing-List: contact lucene-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Lucene Developers List" Reply-To: "Lucene Developers List" Delivered-To: mailing list lucene-dev@jakarta.apache.org Received: (qmail 77359 invoked from network); 1 Dec 2003 23:33:24 -0000 Received: from unknown (HELO c000.snv.cp.net) (209.228.32.72) by daedalus.apache.org with SMTP; 1 Dec 2003 23:33:24 -0000 Received: (cpmta 5567 invoked from network); 1 Dec 2003 15:33:30 -0800 Received: from 24.51.109.181 (HELO ehatchersolutions.com) by smtp.hatcher.net (209.228.32.72) with SMTP; 1 Dec 2003 15:33:30 -0800 X-Sent: 1 Dec 2003 23:33:30 GMT Date: Mon, 1 Dec 2003 18:33:37 -0500 Subject: Re: VOTE: BooleanQuery$TooManyClauses Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Erik Hatcher To: "Lucene Developers List" Content-Transfer-Encoding: 7bit In-Reply-To: <3FCB8222.4090607@lucene.com> Message-Id: X-Mailer: Apple Mail (2.553) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N 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