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
