Return-Path: Delivered-To: apmail-jakarta-lucene-dev-archive@www.apache.org Received: (qmail 56153 invoked from network); 1 Dec 2003 18:02:19 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 1 Dec 2003 18:02:19 -0000 Received: (qmail 38543 invoked by uid 500); 1 Dec 2003 18:02:09 -0000 Delivered-To: apmail-jakarta-lucene-dev-archive@jakarta.apache.org Received: (qmail 38517 invoked by uid 500); 1 Dec 2003 18:02:09 -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 38488 invoked from network); 1 Dec 2003 18:02:08 -0000 Received: from unknown (HELO sccrmhc13.comcast.net) (204.127.202.64) by daedalus.apache.org with SMTP; 1 Dec 2003 18:02:08 -0000 Received: from lucene.com (c-24-5-145-151.client.comcast.net[24.5.145.151]) by comcast.net (sccrmhc13) with SMTP id <2003120118021101600t1raje>; Mon, 1 Dec 2003 18:02:12 +0000 Message-ID: <3FCB8222.4090607@lucene.com> Date: Mon, 01 Dec 2003 10:02:10 -0800 From: Doug Cutting User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lucene Developers List Subject: VOTE: BooleanQuery$TooManyClauses References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 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