Perché le eccezioni controllate rispetto a quelle non selezionate chiamate "la controversia" nel tutorial di Oracle Java?

Sono nuovo di Java e stavo leggendo la sua documentazione sulle eccezioni. , e in particolare la pagina Eccezioni non controllate - La controversia .

La linea di fondo dice:

Se si può ragionevolmente prevedere che un client si ripristini da un'eccezione, impostarlo come un'eccezione selezionata. Se un client non può fare nulla per ripristinare l'eccezione, impostalo come un'eccezione non selezionata.

Non capisco l'articolo. In che cosa consiste la "controversia"? Puoi spiegarlo in parole semplici?

java api-design exceptions

— ABcDexter
fonte

Possibile duplicato di Checked vs Unchecked vs No Exception ... Una buona pratica di convinzioni contrarie

— moscerino

vedi anche: In Java, a cosa servono le eccezioni controllate?

— moscerino del

Per favore, vedi la domanda aggiornata, non credo che sia un duplicato :)

— ABcDexter,

"Ho provato a leggerlo" , cosa è successo?

— Inutile

Si chiama così perché ci sono molte controversie su questo argomento. Vedi anche questa domanda StackOverflow: il caso contro le eccezioni controllate che menziona alcune citazioni di persone famose / influenti

— Hulk,

Risposte:

Prima ti faccio un esempio (ma alla fine c'è la risposta alla controversia).

Supponiamo che tu stia modificando un documento in un editor di documenti basato su Java e dopo aver finito scegli File-> Salva con nome ... e hai scelto di salvare il documento in un volume su cui non hai i permessi di scrittura. L'Editor non si arresterebbe con un brutto stacktrace, ti direbbe semplicemente che non poteva salvare il file e ti avrebbe permesso di continuare a modificarlo e / o salvarlo in un'altra posizione.

In tal caso, probabilmente si aspettava un'eccezione verificata, catturata e attuata per riprendersi gentilmente da essa.

D'altra parte, supponi una divisione per zero o un'eccezione puntatore nulla causata da un errore di programmazione che solleva la sua brutta testa solo in determinate condizioni. Ciò potrebbe accadere in qualsiasi parte del codice, la RAM può essere danneggiata, ecc. Nessun documento API ti direbbe "questo metodo genererebbe una divisione per zero se la RAM fosse corrotta" .

Le eccezioni verificate dovrebbero far parte del progetto e gli utenti di tale API dovrebbero prepararsi a gestirle. Eccezioni non controllate potrebbero verificarsi quasi ovunque e sono al di fuori del nostro controllo.

La controversia sorge dai programmatori che utilizzano eccezioni non controllate (che si estendono da RuntimeException) quando dovrebbero usare eccezioni controllate:

come scorciatoia per non essere disturbato dal compilatore
per rendere le loro firme più semplici
perché ritengono che le eccezioni controllate siano un problema di dipendenza (se si lancia una nuova eccezione controllata in una classe di implementazione, è necessario modificare la firma dell'interfaccia) e viceversa.

— Tulains Córdova
fonte

"dovresti modificare la firma dell'interfaccia" - beh, sei anche costretto a farlo dal compilatore e dovrai gestirlo o dichiararlo per essere lanciato in ogni sito di chiamata.

— Hulk,

Il fatto che un'applicazione dell'interfaccia utente gestisca correttamente un errore in modo intuitivo si basa sulla capacità del programmatore di scrivere il codice. Possono scrivere bene il codice in questo modo con eccezioni non controllate, così come qualcun altro può gestire erroneamente gli errori con eccezioni verificate. L' intenzione delle eccezioni verificate è di semplificare la gestione corretta degli errori da parte dei programmatori. La controversia non è ciò che hai affermato qui, ma piuttosto se effettivamente raggiungono con successo l'obiettivo di rendere più semplice la gestione degli errori. Dal punto di vista di molti, non lo fanno; lo rendono più difficile.

— Servito il

@Servy In quale modo intuitivo un'app UI può gestire il fatto di un chip RAM difettoso o di rimanere senza cicli CPU perché un altro software non funziona correttamente?

— Tulains Córdova,

@ TulainsCórdova In entrambi i casi il programma non verrà nemmeno eseguito , quindi non esiste un periodo di gestione delle eccezioni , quindi il modo in cui si tenta di rappresentare un errore è irrilevante quando non si è nemmeno in grado di eseguire nessuno dei codice quando succede.

— Servito il

@ TulainsCórdova Non devi necessariamente aver riscontrato l'errore per gestirlo, ma sì, il compilatore non ti dirà che potrebbe essere lanciato. La controversia è se il compilatore che ti dice che l'eccezione potrebbe essere generata sia effettivamente utile. Alcuni pensano che lo sia, altri pensano che non lo sia. La domanda qui è qual è la controversia , e questa è la risposta. La tua affermazione su quale sia la controversia fondamentale delle eccezioni verificate non lo è.

— Servito il

-4

Non ci sono polemiche su quella pagina. È Oracle che dice alle persone di usare le eccezioni controllate.

La falsa "controversia" che hanno inventato qui è tra i progettisti e gli utenti delle lingue. I progettisti hanno permesso alle persone di lanciare e catturare cose che (nella loro mente) non dovrebbero essere gettate o catturate. Quindi hanno creato una pagina web lamentandosi degli sviluppatori pigri.

— ascotan
fonte

V'è una polemica, anche se quella pagina dice poco su di esso. Ciò che è controverso è la risposta alla domanda "Le eccezioni controllate aiutano o ostacolano lo sviluppo di un software migliore?" E "In tal caso, quali eccezioni dovrebbero essere verificate e quali dovrebbero essere deselezionate?" Scommetto che potresti iniziare una vivace discussione se avessi abbastanza sviluppatori (e birra) insieme in una stanza per rispondere a queste domande.

— Solomon Slow