Nella progettazione di moduli riusabili riveste grande importanza la gestione delle eccezioni.
Ma cos'è un eccezione e come si distingue da un errore?
- un eccezione è una rottura delle assunzioni predefinite dell’applicazione
esempio: l’assunzione che la connessione al database sia disponibile;
- un errore è un'assunzione non definita in modo corretto
esempio: inserimento di un valore null in un campo del database che non prevede l’inserimento di valori null.
Gli errori devono essere tutti gestiti, cioè evitati, scrivendo del buon codice. Le eccezioni, che con una buona progettazione possono essere tutte previste, devono essere gestite in modo opportuno.
Non mi soffermerò sull’uso del costrutto
try,
catch,
finaly, ma piuttosto su come gestire un eccezione e come tentare di progettare un’applicazione rubusta e scalabile in riferimento alle eccezioni.
Al verificarsi di un eccezione si possono scegliere tre opzioni:
- Ignorare l’eccezione ed eseguire l’istruzione seguente, come se non ci fosse stata nessuna anomalia.
- Catturare l’eccezione ed eseguire del codice che gestisce l’anomalia.
- Catturare l’eccezione ed incapsularla in un’altra eccezione che è rilevante per la nostra applicazione, o per il modulo/layer chiamante che a sua volta si troverà davanti alla 3 opzioni descritte.
Quest’ultimo caso ovviamente, fa la differenza e necessità di un set di eccezioni personalizzate.
Sia
.Net che
Java permettono l' estensione della classe
exception, creando eccezioni che possono essere usate per fornire informazioni più dettagliate, e/o per incapsulare una determinata eccezione, e/o per agevolare la sua gestione.
Per una efficiente gestione è opportuno quindi creare un set di eccezioni per ogni "componente" o "layer". Così gli altri componenti che usano tale oggetto, una volta catturato l'errore potranno decidere se e come gestirlo oppure propagarlo a sua volta all'eventuale altro modulo chiamante (magari incapsulando il messaggio in un'eccezione di sua competenza).
Di fondamentale importanza è il giusto ordine delle eccezioni nel blocco Catch: vanno indicate dal più specifico al più generico.
Riassumendo, è necessario:
- evitare richieste all’utente su come gestire un eccezione;
- evitare di nascondere eccezioni al chiamante, diminuisce la visibilità e la chiarezza sugli algoritmi applicati. Meglio generare un eccezione, sarà il modulo chiamante a gestire l’anomalia;
- evitare errori generici, ma creare o usare eccezioni specifiche che migliorano la conoscenza dell’anomalia generata e quindi la sua gestione da parte di moduli chiamanti;
- usare il costrutto finally;
- creare una gestione dell’eccezione in grado di ripristinare uno stato consistente in caso di anomalia.
