[jira] [Comment Edited] (LUCENE-4649) kill ThreadInterruptedException

["Uwe Schindler (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LUCENE-4649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13540516#comment-13540516 ] 

Uwe Schindler edited comment on LUCENE-4649 at 12/28/12 5:12 PM:
-----------------------------------------------------------------

+1

The ThreadInterruptedException is a large problem with multithreaded code, as it fails to communicate the root cause and is not checked! The InterruptedException is checked in the JDK because *you* have to do something.

If you want to remove the checked InterruptedException and make it a unchecked or IOException subclass, you have to restore interrupted status, otherwise it can happen that your threads hang, because your code does not recognize the interruption. It is good that we "now marked all critical codepaths" with this useless runtime ex, we can no look at each code part when removing it and fix it to restore interrupted status.

A major problem is also to catch Throwable or Exception and wrap it by another exception, because it also looses the interrupt status. -E.g. IOUtils.close...() must also not suppress this (unless it is rethrown as original InterruptedException).- <-- this is not the case, IOUtils is fine, because it can never catch InterruptedException, as Closeable.close may not throw it (Closeable allows only the checked IOException).
                
      was (Author: thetaphi):
    +1

The ThreadInterruptedException is a large problem with multithreaded code, as it fails to communicate the root cause and is not checked! The InterruptedException is checked in the JDK because *you* have to do something.

If you want to remove the checked InterruptedException and make it a unchecked or IOException subclass, you have to restore interrupted status, otherwise it can happen that your threads hang, because your code does not recognize the interruption. It is good that we "now marked all critical codepaths" with this useless runtime ex, we can no look at each code part when removing it and fix it to restore interrupted status.

A major problem is also to catch Throwable or Exception and wrap it by another exception, because it also looses the interrupt status. E.g. IOUtils.close...() must also not suppress this (unless it is rethrown as original InterruptedException).
                  
> kill ThreadInterruptedException
> -------------------------------
>
>                 Key: LUCENE-4649
>                 URL: https://issues.apache.org/jira/browse/LUCENE-4649
>             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 java.io.InterruptedIOException("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: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org