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
