Modo corretto per gestire Thread.interrupted() in un Callable?

Question

Qual è il modo corretto di gestire Thread.interrupted() in un Callable? Immagino che il callable debba lanciare un InterruptedException; ad esempio:

public class MyCallable implements Callable<Object> { 
    public Object call() { 
     Object result = null; 

     // Simulate long-running operation that calculates result 
     while (true) { 
      ... 
      if (Thread.interrupted()) { 
       throw new InterruptedException(); 
      } 
     } 

     result = ... // something produced by the long-running operation  

     return result; 
    } 
} 

È corretto oppure esiste un modo più appropriato di gestirlo? Grazie.

Answer 1

Edit:

Dopo un po 'avanti e indietro, sembra che si vuole essere in grado di interrompere la vostra routine IO. Questo sembra un buon lavoro per alcune delle classi NIO InterrutibleChannel. Ad esempio, la lettura dal seguente numero BufferedReader è interrompibile e genera InterruptedIOException. Vedi qui per more examples of the NIO code.

BufferedReader in = new BufferedReader(new InputStreamReader(
    Channels.newInputStream((new FileInputStream(
     new File(...))).getChannel()))); 

Quindi, è possibile chiamare future.cancel() che interrompere il filo e causare IO per gettare un InterruptedIOException. Se ciò accade, potresti non catturare il IOException e lasciarlo fuoriuscire dal metodo call().

---

Se si desidera passare indietro al Future che il metodo call() è stata interrotta poi penso che gettando InterruptedException va bene. Un'altra opzione potrebbe essere solo return null; o qualche altro oggetto indicatore dal tuo metodo call(). Questo è tipicamente quello che faccio se un thread è stato interrotto.

Una cosa da ricordare è che se tiri call()InterruptedException, quando si fa un future.get() si getterà un ExecutionException e la causa di tale eccezione sta per essere un InterruptedException. Non essere confuso dal fatto che lo future.get() può anche lanciare uno InterruptedException se il get(long timeout, TimeUnit unit) è scaduto.

try { 
    result = future.get(); 
} catch (ExecutionException e) { 
    if (e.getCause() instanceof InterruptedException) { 
     // call() method was interrupted 
    } 
} catch (InterruptedException e) { 
    // get was interrupted 
} 

Se, tuttavia, future.cancel(true) si chiamava allora la future.get() sarà gettare un CancellationException invece.

Answer 2

Dipende in realtà da come si desidera che il thread sia in attesa su get(). Se non si desidera che il thread in attesa di avere un eccezione generata allora non si vuole throw new InterruptedException

Immaginate

try{ 
    future.get(); 
}catch(ExecutionException ex){ 

}catch(InterruptedException em){ 

} 

Se si verifica alcuna eccezione che cosa ci si aspetta di essere? Nel tuo caso è un ExecutionException. Se non vuoi un ExecutionException allora non dovresti rilanciare l'InterruptedException.