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 <u...@thetaphi.de> 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: u...@thetaphi.de > > >> -----Original Message----- >> From: Michael McCandless [mailto:luc...@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. If 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 <u...@thetaphi.de> 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 IO >> > 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: u...@thetaphi.de >> > >> >> -----Original Message----- >> >> From: Michael McCandless [mailto:luc...@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? Technically I think it's the right thing to >> >> do, but, I started to implement it and found that it basically results >> >> in nearly every API now throwing InterruptedException (just like >> >> IOException). >> >> >> >> Thoughts? >> >> >> >> Mike >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org >> >> For additional commands, e-mail: java-dev-h...@lucene.apache.org >> > >> > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org >> > For additional commands, e-mail: java-dev-h...@lucene.apache.org >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: java-dev-h...@lucene.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
