Perché InterruptedException è un'eccezione controllata?

Question

Questa è una domanda sulla vecchia Java quando stavamo creando i nostri thread. Alcuni metodi come Thread.sleep(100) generano uno InterruptedException quando viene interrotto da un altro thread. Ora, a quanto ho capito, un'interruzione significa che un altro thread sta dicendo: Lasciami prendere il controllo ora.

Quando ciò accade, perché Java vuole che ci occupiamo di InterruptedException?

Il programmatore non dovrebbe nemmeno aver bisogno di preoccuparsi quando i fili si interrompono a vicenda. Dovrebbe essere solo in grado di dividere il lavoro tra i fili e di essere notificato quando è fatto. Quindi, qual è la ragione per cui Java ci vuole trattare con InteruptedException? Per lo meno dovrebbe essere RuntimeException

Answer 1

Il programmatore non dovrebbe nemmeno bisogno di preoccuparsi quando i fili sono interrompendosi a vicenda

Questo non è vero. Ci sono molte, molte situazioni in cui vuoi sapere che è stata richiesta un'interruzione, ma la ignorerai per un po 'per finire il lavoro che stai facendo.

Ad esempio, si supponga che un thread apra un file e inizi a scrivere alcuni dati. Questo thread, quindi, blocca, in attesa del resto dei dati da calcolare. Supponiamo che un secondo thread cerchi di interrompere il primo. Cosa dovrebbe fare? Semplicemente muori, e forse finisci con un file corrotto, incompleto? Dovrebbe essere ripulito eliminando il file che ha iniziato a scrivere? Dovrebbe ignorare la richiesta di interruzione e aspettare solo la fine dei dati che deve scrivere? Dovrebbe scrivere qualcosa che significa "Sono stato interrotto qui", in modo che possa continuare il suo lavoro da quel punto la prossima volta?

In uno scenario diverso, si supponga di disporre di un server HTTP. Supponiamo che gli utenti stiano accedendo al tuo server e, per esempio, scaricando un grosso file da esso. Vuoi fermare il server. L'applicazione proverà quindi ad interrompere tutti i thread di lavoro. Cosa dovrebbero fare? Basta interrompere i download? O dovrebbero aspettare che gli utenti finiscano di scaricare i loro file e solo dopo che dovrebbero morire, senza accettare altre richieste? Entrambi gli scenari sono ugualmente validi.

Come vedete, ci sono troppi scenari possibili e sarebbe terribile se non avessimo modo di sapere che è stata richiesta un'interruzione. A volte, lascerai semplicemente che il thread muoia. A volte, è necessario ripulire l'ambiente. A volte, vuoi che finisca la richiesta su cui sta lavorando, ma non accetti altre richieste.

Answer 2

Sembra che tu stia mescolando tra lo schedulatore e l'interruzione.

Uno scheduler di thread è piuttosto un sistema nativo, che divide i processi da più thread in processi. Se sono attivi troppi thread, lo scheduler funzionerà in modo asincrono. In altre parole lasciatemi prendere in carico per ora potrebbe essere proprio vero.

Un interrupt significa, uscire da ciò che si sta facendo attualmente e non tornare ad esso. Il modo più pratico per implementarlo è un'eccezione.

Answer 3

Viene generato uno InteruptedException quando un thread viene forzatamente interrotto. Questa non è una situazione usuale (cioè quando il thread è contesto disattivato dallo scheduler). Gli esempi potrebbero essere quando un altro thread manually interupts it o il processo riceve un segnale SIGINT.

Answer 4

Le runtimeException rappresentano gli errori di programmazione (vedere http://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html). InterruptedException è più simile a un segnale di un altro thread.