lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <>
Subject RE: Thread.interrupt()
Date Wed, 28 Oct 2009 12:37:36 GMT
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 Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen

> -----Original Message-----
> From: Michael McCandless []
> Sent: Wednesday, October 28, 2009 12:54 PM
> To:
> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message