Ti darò un esempio prima (ma alla fine è la risposta perché la controversia).
Consideriamo che stai modificando un documento in un editor di documenti basato su Java e dopo aver finito hai scelto File- > Salva come ... e hai scelto di salvare il documento in un volume che non hai permessi di scrittura sopra. L'Editor non si schianterà su di te con un brutto stacktrace, ti dirà semplicemente che non è possibile salvare il file e ti permetterebbe di continuare a modificare e / o salvare in un'altra posizione.
In questo caso è probabile che ci si aspettasse un'eccezione controllata, catturata e gestita per poterla recuperare graziosamente.
D'altra parte suposse questi una divisione per zero o un'eccezione di puntatore nullo causata da un errore di programmazione che alza la sua brutta testa solo in certe condizioni. Questo potrebbe accadere ovunque nel codice, la RAM può essere danneggiata, ecc. Nessun documento API ti direbbe "questo metodo genererebbe una divisione per zero se la RAM è corrotta" .
Le eccezioni controllate dovrebbero essere parte del design e gli utenti di tale API dovrebbero prepararsi a gestirle. Le eccezioni non controllate potrebbero verificarsi quasi ovunque e sono al di fuori del nostro controllo.
La controversia deriva dai programmatori che utilizzano eccezioni non controllate (che si estendono da RuntimeException) quando dovrebbero utilizzare eccezioni controllate:
- come shorcut per non essere disturbato dal compilatore
- per rendere le loro firme più semplici
- perché considerano che le eccezioni controllate sono un problema di dipendenza (se lanci una nuova eccezione controllata in una classe di implementazione dovresti modificare la firma dell'interfaccia) e viceversa.