Eccezioni: considerazioni!
Le eccezioni sono errori? Una risposta opportuna potrebbe essere: "non solo"!
Il modo più rapido per presentare le eccezioni in Java è sicuramente quello di proporle come l'equivalente degli errori della programmazione orientata alla procedure. Questa visione, però, non è esaustiva e può essere a volte fuorviante specie per chi è agli inizi nello sviluppo di software object oriented: le eccezioni, nel mondo Java, sono comunque oggetti e come tali necessitano di un design e di valutazioni relative alle performance!
Un ulteriore aspetto legato alle eccezioni è quello di esprimere violazione di un contratto: i metodi di una classe propongono dei veri e propri contratti con gli utilizzatori dell'astrazione. Il mancato rispetto di quanto espresso dall'interfaccia di un metodo è una condizione particolare nella vita di un software, in quanto ci si aspettano dei WELL-BEHAVIOURED CLIENTS: il termine eccezione, quindi, non è casuale ma è stato scelto per ricordarci che questa tipologia di oggetti serve ad esprimere eventi eccezionali nella vita di un artifatto che non necessariamente sono errori!
Regola Generale
Quanto sinora esposto purtroppo non aiuta lo sviluppatore da un punto di vista pratico ed in breve tempo la gestione delle eccezioni diventa un fastidio!
Una prima considerazione che potrebbe aiutare è individuare quando risulta opportuno usare le eccezioni. La regola base che ci può servire esiste: "Se un metodo incontra una condizione anormale che non può gestire dovrebbe lanciare un'eccezione; questo implica che bisognerebbe evitare di usare eccezioni per indicare condizioni che possono essere ragionevolmente indicate come tipiche del funzionamento di un metodo".
La regola ora espressa è comunque generica: come si applica nella realtà?
Un esempio immediato ci è fornito dal concetto di ITERATORE così come formalizzato nell'interfaccia java.util.Iterator.
Quando vogliamo scorrere gli elementi di una collezione di dati chiediamo un iteratore che fornisce i seguenti metodi:
boolean hasNext()
|
Ritorna TRUE se ci sono altri elementi su cui iterare
|
Object next()
|
Ritorna il prossimo elemento nell'iterazione
|
void remove()
|
Rimuove dalla collezione l'ultimo elemento ritornato da un iterator.
|
Uno sviluppatore Java sfrutta l'iteratore con un pattern basilare, molto
semplice:
Iterator iterator = someCollection.iterator();
while (iterator.hasNext()) {
doSomething(iterator.next());
}
Le eccezioni sembrano non interessarci ma, in realtà, il metodo next() può lanciare una java.util.NoSuchElementException se invocato quando sono già stati esaminati tutti gli elementi della collezione data. L'uso del codice prima esposto ci garantisce però che l'eccezione discussa non verrà proposta: perché allora è stata scelta questa politica per il metodo next()? Notiamo come prima cosa che il metodo in questione restituisce un reference ad un java.lang.Object, cioè alla root-class di qualsiasi oggetto in Java: questo fa si che non sia possibile adottare la tecnica del "valore speciale" per indicare la fine degli elementi di una collezione! Si potrebbe pensare allora che far lanciare un'eccezione sia stata una soluzione per risolvere il problema di fine-collezione il che ci porterebbe a scrivere codice nella forma:
Iterator iterator = someCollection.iterator();
try {
while (true) {
doSomething(iterator.next());
}
} catch(Exception exc) {
//do some action
}
Questa soluzione sembrerebbe valida ma nasconde dei problemi:
-
L'eccezione potrebbe essere lanciata per altri motivi e non essere quella prevista! Volendo proporre un catch sull'eccezione specifica ...
- ... riscontriamo, comunque, un degrado di prestazioni dovuto alla creazione di un'eccezione e all'attivazione del blocco di catch!
In realtà è possibile verificare una condizione End Of Collection (EoC) in un modo più semplice ed efficace: il metodo hasNext() racchiude la logica per raggiungere questo scopo! È stata, allora, rispettata la regola generale quando ci parla di tipicità di funzionamento: è evidente che una EoC è un qualcosa di prevedibile nella vita di un iteratore ed è anche una condizione verficabile in modo semplice ed efficiente!
Il design del metodo next() ci conferma ulteriormente la regola generale se riflettiamo ancora una volta sull'idea di tipicità di comportamento applicata, questa volta, sul contratto proposto dal metodo stesso. Tale contratto ci dice che è possibile ottenere il prossimo elemento nella collezione se questo esiste. Il punto è che ci si aspetta che un cliente rispetti la regola di esistenza del prossimo elemento anche perché esiste un metodo preposto a tale scopo: se ciò non accade c'è una violazione! Violare il contratto è un evento eccezionale che deve essere trattato come tale ed ecco che la soluzione di design di adottare una java.util.NoSuchElementException è pienamente giustificata.
... e dopo?
Nel prossimo articolo verranno proposte altre regole pratiche che ci permetteranno di espandere la visione offerta dalla regola generale e di sfruttare il mondo delle eccezioni in modo più opportuno senza odiare un framework che in realtà può esserci di notevole aiuto!
Discuti sul forum
Stampa
![[LM]](../../../images/skin/default/icons/lm_sm.png){kind=icon}
.
Made with GIMP
& WPP.