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
