Le eccezioni rendono davvero facile scrivere codice in cui un'eccezione generata interromperà le invarianti e lascerà gli oggetti in uno stato incoerente. Essenzialmente ti costringono a ricordare che la maggior parte delle affermazioni che fai può potenzialmente lanciare e gestirlo correttamente. Farlo può essere complicato e controintuitivo.
Considera qualcosa di simile come un semplice esempio:
class Frobber
{
int m_NumberOfFrobs;
FrobManager m_FrobManager;
public:
void Frob()
{
m_NumberOfFrobs++;
m_FrobManager.HandleFrob(new FrobObject());
}
};
Supponendo che la FrobManagervolontà deletedel FrobObject, questo sembra ok, giusto? O forse no ... Immagina quindi se uno dei due FrobManager::HandleFrob()o operator newlancia un'eccezione. In questo esempio, l'incremento di m_NumberOfFrobsnon viene annullato. Pertanto, chiunque utilizzi questa istanza di Frobberavrà un oggetto potenzialmente danneggiato.
Questo esempio può sembrare stupido (ok, mi sono dovuto sforzare un po 'per costruirne uno :-)), ma la conclusione è che se un programmatore non pensa costantemente alle eccezioni e si assicura che ogni permutazione di stato venga annullata ogni volta che ci sono lanci, ti metti nei guai in questo modo.
Ad esempio, puoi pensarlo come pensi ai mutex. All'interno di una sezione critica, fai affidamento su diverse istruzioni per assicurarti che le strutture dati non siano danneggiate e che gli altri thread non possano vedere i tuoi valori intermedi. Se una qualsiasi di queste affermazioni non viene eseguita casualmente, finisci in un mondo di dolore. Ora togli i blocchi e la concorrenza e pensa a ciascun metodo in questo modo. Pensa a ogni metodo come una transazione di permutazioni sullo stato dell'oggetto, se vuoi. All'inizio della chiamata al metodo, l'oggetto dovrebbe essere in stato pulito e alla fine dovrebbe esserci anche uno stato pulito. Nel mezzo, la variabile foopotrebbe non essere coerente conbar, ma il tuo codice alla fine lo rettificherà. Ciò che significa eccezioni è che qualsiasi tua dichiarazione può interromperti in qualsiasi momento. Spetta a te in ogni singolo metodo farlo correttamente e tornare indietro quando ciò accade, o ordinare le tue operazioni in modo che i lanci non influenzino lo stato dell'oggetto. Se sbagli (ed è facile commettere questo tipo di errore), il chiamante finisce per vedere i tuoi valori intermedi.
Metodi come RAII, che i programmatori C ++ amano menzionare come la soluzione definitiva a questo problema, fanno molto per proteggersi da questo. Ma non sono una pallottola d'argento. Ti assicurerà di rilasciare risorse al momento del lancio, ma non ti libera dal dover pensare alla corruzione dello stato dell'oggetto e ai chiamanti che vedono valori intermedi. Quindi, per molte persone, è più facile a dirsi, in base allo stile di codifica, senza eccezioni . Se limiti il tipo di codice che scrivi, è più difficile introdurre questi bug. Se non lo fai, è abbastanza facile commettere un errore.
Sono stati scritti interi libri sulla codifica sicura delle eccezioni in C ++. Molti esperti hanno sbagliato. Se è davvero così complesso e ha così tante sfumature, forse è un buon segno che devi ignorare quella caratteristica. :-)