Linee guida nella scrittura di codice #10: Le eccezioni

Generalmente un’eccezione viene generata quando un membro non riesce a portare a termine il compito per il quale è stato creato. Se ad esempio il metodo Open() dell’oggetto Connection non riesce a connettersi al database, genererà  una eccezione in quanto non è riuscito a svolgere il suo compito che è quello di aprire una connessione con il DBMS. Naturalmente anche noi possiamo non solo gestire ma anche generare delle eccezioni.

In caso di errore, utilizzare sempre le eccezioni per comunicare l’accaduto e mai valori di ritorno quali codici di errore o messaggi predefiniti. Questo perché altrimenti si verrebbe a creare una situazione di ambiguità  con conseguente perdita di standardizzazione.

Valutare di volta in volta l’opportunità  di utilizzare il metodo System.Environment.FailFast(System.String) per terminare il processo attivo in tutti quei casi in cui il verificarsi di una eccezione comporta un pericolo nella prosecuzione dell’esecuzione perchè magari ci si potrebbe trovare con dati non validi o peggio potrebbero verificarsi perdite di dati. Questo metodo è disponibile a partire dalla versione 2.0 del .NET Framework.

Non utilizzare le eccezioni per gestire il normale flusso di esecuzione dell’applicazione in quanto questo comporta tutta una serie di svantaggi tra cui il non trascurabile degrado in termine di prestazioni. Tentare invece quanto più possibile di evitare, con opportuni controlli e verifiche preliminari, tutti quei casi che possano portare al verificarsi di una eccezione. Una eccezione dovrebbe generarsi solo in casi realmente imprevedibili e non evitabili a priori. Banalmente, se un metodo accetta come parametro una stringa e il presentarsi di una stringa null sicuramente causerebbe un errore, inserire un semplice controllo if( stringa != null) per scongiurare questa eventualità .

Evitare la creazione di membri pubblici che diano una eccezione come valore di ritorno o come parametro out.

àˆ consigliabile creare metodi specifici che generino le eccezioni per poi richiamare questi di volta in volta negli altri metodi invece di ripetere ogni volta il codice necessario per la generazione dell’eccezione. Il metodo generatore non deve però generare l’eccezione all’interno di se stesso ma soltanto creare l’oggetto exception e restituirlo come valore di ritorno al metodo chiamante che ne ha fatto richiesta. Questo per evitare che lo stack non rifletti correttamente la sequenza di chiamate che ha portato alla generazione dell’eccezione.

Evitare se possibile di generare eccezioni dall’interno di blocchi finally.