Return-Path: Delivered-To: apmail-lucene-java-dev-archive@www.apache.org Received: (qmail 35188 invoked from network); 30 Oct 2009 22:02:38 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 30 Oct 2009 22:02:38 -0000 Received: (qmail 97886 invoked by uid 500); 30 Oct 2009 22:02:38 -0000 Delivered-To: apmail-lucene-java-dev-archive@lucene.apache.org Received: (qmail 97808 invoked by uid 500); 30 Oct 2009 22:02:37 -0000 Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-dev@lucene.apache.org Delivered-To: mailing list java-dev@lucene.apache.org Received: (qmail 97800 invoked by uid 99); 30 Oct 2009 22:02:37 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 30 Oct 2009 22:02:37 +0000 X-ASF-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [209.85.210.192] (HELO mail-yx0-f192.google.com) (209.85.210.192) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 30 Oct 2009 22:02:34 +0000 Received: by yxe30 with SMTP id 30so3558742yxe.29 for ; Fri, 30 Oct 2009 15:02:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.254.8 with SMTP id b8mr4044758ybi.136.1256940128595; Fri, 30 Oct 2009 15:02:08 -0700 (PDT) In-Reply-To: <710E38F80B7346288A6A52AE302A684C@VEGA> References: <9ac0c6aa0910280453y1c35c80dr204713f202bde244@mail.gmail.com> <9ac0c6aa0910280547l2d929ae9k376ccba121c299d3@mail.gmail.com> <710E38F80B7346288A6A52AE302A684C@VEGA> Date: Fri, 30 Oct 2009 18:02:08 -0400 Message-ID: <9ac0c6aa0910301502v7455a714v2ad5119d7430766@mail.gmail.com> Subject: Re: Thread.interrupt() From: Michael McCandless To: java-dev@lucene.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I don't think this is really an IOException? IOException should be for things IO related... eg your disk filled up, something's wrong with the filesystem, permissions are wrong, etc. Whereas this exception is trying to tell you "hey, you interrupted me, so, I stopped". Also, I don't think it's good to have existing IOException handlers handle this, upon upgrading to 3.0: we are now wrapping the InterruptedException in a RuntimeException, so if we change that to a new class that subclasses IOException instead, it's a subtle break in back-compat. Though I'd imagine not many apps are relying on getting a RuntimeException upon interrupting Lucene... Mike On Wed, Oct 28, 2009 at 8:55 AM, Uwe Schindler wrote: > In this case (unchecked ex), we could have done that in 2.9, too :-) > > I would prefer IOException so normal handlers would catch it and stop > indexing with a standard IO error (it is in fact an IOError, because > IndexWriter is not able to complete the merge). If somebody ignores a > IOException, it's his fault and his code will not work correctly. > > ----- > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: uwe@thetaphi.de > > >> -----Original Message----- >> From: Michael McCandless [mailto:lucene@mikemccandless.com] >> Sent: Wednesday, October 28, 2009 1:48 PM >> To: java-dev@lucene.apache.org >> Subject: Re: Thread.interrupt() >> >> OK, I agree we shouldn't burden people with another checked exception. >> >> But we should differentiate it, so our own exception, subclassing >> either RuntimeException or IOException sounds good. >> >> I think I'd prefer subclassing RuntimeException so that existing >> handlers do not in fact suppress it. =A0If you are advanced enough to be >> calling Thread.interrupt (or using Futures, which can call >> Thread.interrupt), then you should be able to handle the resulting >> unchecked exception? >> >> Mike >> >> On Wed, Oct 28, 2009 at 8:37 AM, Uwe Schindler wrote: >> > I have seen this yesterday, too (when coming around the assert >> > Thread.holdsLock()), but I would not do that. How about defining a >> subclass >> > of RuntimeException like InterruptedRuntimeException, so it does not >> need to >> > be declared, but one could still catch it. >> > >> > Normally an interrupt inside Lucene would normally break a lot, so it = is >> not >> > done alone with catching it in user code? InterruptedException is only >> > useful if you want to really control coexistence of threads or break I= O >> > operations, but I would not recommend to interrupt any foreign thread >> not >> > part of your code (like a merging thread). If this was done by someone= , >> we >> > are fine with throwing a fatal error in the indexer. Maybe make it a >> > subclass of IOException (because the indexing IO is interrupted)? >> > >> > Uwe >> > >> > ----- >> > Uwe Schindler >> > H.-H.-Meier-Allee 63, D-28213 Bremen >> > http://www.thetaphi.de >> > eMail: uwe@thetaphi.de >> > >> >> -----Original Message----- >> >> From: Michael McCandless [mailto:lucene@mikemccandless.com] >> >> Sent: Wednesday, October 28, 2009 12:54 PM >> >> To: java-dev@lucene.apache.org >> >> Subject: Thread.interrupt() >> >> >> >> As a followon to LUCENE-1573, we had stated that in 3.0 instead of >> >> throwing RuntimeException when a Thread inside Lucene is interrupted, >> >> we would throw InterruptedException. >> >> >> >> Do we want to do this? =A0Technically I think it's the right thing to >> >> do, but, I started to implement it and found that it basically result= s >> >> in nearly every API now throwing InterruptedException (just like >> >> IOException). >> >> >> >> Thoughts? >> >> >> >> Mike >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org >> >> For additional commands, e-mail: java-dev-help@lucene.apache.org >> > >> > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org >> > For additional commands, e-mail: java-dev-help@lucene.apache.org >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org >> For additional commands, e-mail: java-dev-help@lucene.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org > For additional commands, e-mail: java-dev-help@lucene.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org For additional commands, e-mail: java-dev-help@lucene.apache.org