2012-06-01 33 views
10

Mi rendo conto che c'è beenamplediscussion dei meriti relativi delle eccezioni controllate rispetto alle eccezioni non controllate in Java e non è mia intenzione rivisitare l'intero dibattito.eccezione non controllata che sarebbe stata migliore come controllata

Piuttosto, vorrei fare una domanda molto specifica che mi è venuta in mente mentre stavo leggendo Joshua Bloch's Effective Java, 2nd Edition. Mentre stavo leggendo, ho notato che nella voce 59 ("Evita l'uso non necessario delle eccezioni controllate") Joshua fornisce un esempio nell'API Java in cui viene utilizzata un'eccezione controllata. In particolare, in Object:

protected Object clone() 
      throws CloneNotSupportedException 

... e poi sostiene che avrebbe dovuto essere un'eccezione incontrollato, invece.

Se il programmatore che utilizza l'API non può fare di meglio, un'eccezione non controllata sarebbe più appropriata. Un esempio di eccezione che non supera questo test è CloneNotSupportedException. Viene lanciato da Object.clone, che deve essere invocato solo sugli oggetti che implementano Cloneable (elemento 11). In pratica, il blocco di cattura ha quasi sempre il carattere di un errore di asserzione. La natura verificata dell'eccezione non offre alcun vantaggio al programmatore, ma richiede uno sforzo e complica i programmi.

Poi ho cercato di vedere se aveva un esempio del contrario, ma non sono riuscito a trovarne uno.

Quindi vorrei chiedere se qualcuno può fornire un'API di esempio in Java che utilizza un'eccezione non controllata, ma dove un'eccezione controllata sarebbe stata una scelta migliore e spiegare perché. Sarebbe preferibile un esempio del mondo reale, ma sono aperto a un esempio forzato se ciò illustrasse le cose altrettanto bene.

Modifica: Per coloro che hanno votato per chiuderlo come non costruttivo, voglio chiarire che non sto cercando opinioni, dibattiti, discussioni o discussioni estese. Né sto prendendo un sondaggio. Piuttosto sto cercando riferimenti ad esempi che forniscano una chiara analisi di come i benefici superano i costi. (Implicito in questo è riconoscere che ci sono dei costi). Detto questo, sono scettico sul fatto che la natura di questa domanda lo renda possibile. Penso che se Jon Skeet non può farlo, è improbabile che possa essere fatto. Quindi forse hai ragione. Chiudi se devi

Modifica: Anche se sono indifferente alla risposta, ho intenzione di assegnare questo a Jon solo per il mio tasso di accettazione.

risposta

13

Sì, facilmente: Integer.parseInt genera NumberFormatException che è deselezionato.

Tuttavia, se si analizzano dati potenzialmente non validi, è consigliabile prendere in considerazione l'eccezione: è possibile ignorare tali dati, o magari segnalarli e andare avanti. Non è come Java ha un equivalente di .NET Int32.TryParse che ti permette di facilmente ignorare i dati non validi. Fondamentalmente è necessario sapere che è necessario rilevare l'eccezione, senza la provocazione del compilatore. Grr.

+2

Sono completamente d'accordo. Quando stai codificando e inserisci "la zona" è abbastanza facile perdere quella certa eccezione che sta aspettando di apparire e gridare "pwn3d!" o perché hai dimenticato di prenderlo o perché non sapevi che potresti aver bisogno di prenderlo ... – Gamb

+0

Grazie per la tua rapida risposta, Jon. Hai scelto un esempio che non mi infastidisce. Sono soddisfatto che l'eccezione sia menzionata nel JavaDoc e apprezzo che mi sia concesso di scegliere l'ambito in cui gestire gli argomenti.Credi che ogni esempio arriverà allo stesso compromesso? – pohl

+0

@pohl: Supponi di * chiamare * 'Integer.parseInt' in uno dei tuoi metodi, ma dimentica di prenderlo o dichiararlo. A quel punto, tutti i chiamanti del metodo * that * non hanno idea di cosa potrebbe accadere. Sei ancora contento di quella situazione? –

Problemi correlati