[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=13541628#comment-13541628 ] 

Uwe Schindler edited comment on LUCENE-4649 at 1/1/13 12:41 PM:
----------------------------------------------------------------

bq. OK I see, so the big problem is we are throwing our own exc (ThreadInterruptedException) but failing to set the interrupt bit?

Yes, thats problem #1, the serious part.

bq. 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.

I disagree. The official documentation explicitely mention that IO-related code that gets interrupted must throw java.io.InterruptedIOException which is exactly defined as we use it.

The second big problem of our own custom exception is that interrupts *must* be checked Exceptions, so the caller is forced to handle it! The whole InterruptedException stuff is broken in Java, theoretically InterruptedException should be a fourth type of Throwable and not an Exception, so you cannot catch them accientally when doing: catch (Exception e) \{ ignore \}: Exception (checked), RuntimException (unchecked), Error (checked) and InterruptedException (as 4th type).

If you disagree with InterruptedIOException, the only possible and most clean way would be to make InterruptedException part of all throws clauses clearing interrupted bit, sorry.
                
      was (Author: thetaphi):
    bq. OK I see, so the big problem is we are throwing our own exc (ThreadInterruptedException) but failing to set the interrupt bit?

Yes, thats problem #1, the serious part.

bq. 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.

I disagree. The official documentation explicitely mention that IO-related code that gets interrupted must throw java.io.InterruptedIOException which is exactly defined as we use it.

The second big problem of our own custom exception is that interrupts *must* be checked Exceptions, so the caller is forced to handle it! The whole InterruptedException stuff is broken in Java, theoretically InterruptedException should be a fourth type of Throwable and not an Exception, so you cannot catch them accientally when doing: catch (Exception e) { ignore }: Exception (checked), RuntimException (unchecked), Error (checked) and InterruptedException (as 4th type).

If you disagree with InterruptedIOException, the only possible and most clean way would be to make InterruptedException part of all throws clauses clearing interrupted bit, sorry.
                  
> 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