Ad esempio, molti metodi in framework / JDK potrebbero generare
java.lang.SecurityException
ma questo non è indicato nella firma del metodo (poiché questa è una pratica normalmente riservata alle eccezioni verificate). Voglio sostenere che la dichiarazione di RuntimeExceptions nel metodo sigs ha molti vantaggi (simile al controllo del tipo statico, ad esempio). Sono ubriaco o altro?
Risposte:
Non dichiarerei un'eccezione non controllata nella firma, poiché è fuorviante per l'utente di tale API. Non è più ovvio se l'eccezione debba essere gestita esplicitamente.
Dichiararlo nel javadoc è un approccio migliore poiché consente a qualcuno di gestirlo se lo ritiene necessario, ma sapendo che può ignorarlo se lo desidera. Ciò rende chiara la separazione tra selezionati e non selezionati.
Dal tutorial Oracle Java :
"Se è così utile documentare l'API di un metodo, comprese le eccezioni che può generare, perché non specificare anche le eccezioni di runtime?" Le eccezioni di runtime rappresentano problemi che sono il risultato di un problema di programmazione e, come tale, non ci si può ragionevolmente aspettare che il codice client API si ripristini da esse o che li gestisca in alcun modo. Tali problemi includono eccezioni aritmetiche, come la divisione per zero; eccezioni del puntatore, come il tentativo di accedere a un oggetto tramite un riferimento nullo; e le eccezioni di indicizzazione, come il tentativo di accedere a un elemento dell'array tramite un indice troppo grande o troppo piccolo.
Le eccezioni di runtime possono verificarsi ovunque in un programma e in un programma tipico possono essere molto numerose. Dover aggiungere eccezioni di runtime in ogni dichiarazione di metodo ridurrebbe la chiarezza di un programma.
Dai un'occhiata al javadoc per Collection # add
C'è tutta una serie di eccezioni non controllate menzionate:
Throws:
UnsupportedOperationException - add is not supported by this collection.
ClassCastException - class of the specified element prevents it from being added to this collection.
NullPointerException - if the specified element is null and this collection does not support null elements.
IllegalArgumentException - some aspect of this element prevents it from being added to this collection.
Se hai pazienza, ti consiglio di documentare accuratamente le possibili eccezioni generate dai tuoi metodi in questo modo. In un certo senso, è ancora più importante farlo per le eccezioni non controllate, poiché le eccezioni verificate sono in qualche modo auto-documentate (il compilatore forza il codice chiamante a riconoscerle).
throwsnella firma del metodo. Queste non sono la stessa cosa. Sì, è assolutamente necessario documentare tutte le eccezioni generate dal tuo API, ma la questione non è di questo.
Dal mio punto di vista è meglio dichiarare eccezioni di runtime almeno nel javadoc per il metodo. Dichiararlo nella firma rende ancora più ovvio cosa può accadere quando qualcosa va storto. Questo è il motivo principale per cui suggerisco di fornire queste informazioni.
Cordiali saluti: con il passare del tempo (ora nel 2017) mi sto appoggiando molto di più a documentarli solo in javadoc ed evitare il più possibile le eccezioni controllate.
A mio avviso, le eccezioni non controllate non dovrebbero mai essere dichiarate nella firma del metodo poiché ciò è contrario alla loro natura.
Se, tuttavia, è probabile che un metodo generi alcune eccezioni non controllate, annotando le probabili circostanze in @throws in Javadoc può essere utile per altri che invocano il metodo per capire cosa può andare storto. Questo è utile solo per le eccezioni che è probabile che i chiamanti siano in grado di gestire (come un NPE dovuto a un input errato, ecc.)
Questo ha a che fare con la discussione sulle eccezioni controllate . La maggior parte sarebbe d'accordo sul fatto che le eccezioni non dovrebbero essere dichiarate nelle firme dei metodi.
C'è anche una discussione su come dovrebbero essere usate le eccezioni di runtime. Sono d'accordo con un poster che le eccezioni di runtime dovrebbero denotare un errore di programmazione o una condizione fatale. Quindi non c'è molto merito nel dichiararli nella firma. Ogni metodo potrebbe potenzialmente tramite uno.