lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <>
Subject [jira] [Commented] (LUCENE-4649) kill ThreadInterruptedException
Date Tue, 01 Jan 2013 12:06:12 GMT


Michael McCandless commented on LUCENE-4649:

OK I see, so the big problem is we are throwing our own exc (ThreadInterruptedException) but
*failing* to set the interrupt bit?  Ie this is a violation of the protocol (we can only clear
the interrupt status if we throw the true, checked InterruptedException).  I agree with that.

But, I don't see why we should pretend that you hit an IOException when in fact we were interrupted?
 That seems worse than throwing ThreadInterruptedExc.
> kill ThreadInterruptedException
> -------------------------------
>                 Key: LUCENE-4649
>                 URL:
>             Project: Lucene - Core
>          Issue Type: Bug
>            Reporter: Robert Muir
> the way we currently do this is bogus.
> For example in FSDirectory's fsync, i think we should instead:
> {noformat}
> } catch (InterruptedException ie) {
> - throw new ThreadInterruptedException(ie);
> + Thread.currentThread().interrupt(); // restore status
> + IOException e = new"fsync() interrupted");
> + e.initCause(ie);
> + throw e;
> {noformat}
> and crazy code in IndexWriter etc that catches ThreadInterruptedExc just to restore status
should be removed. 
> Instead the guy doing the catch (InterruptedException) should do the right thing.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

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

View raw message