Risposta.

In C++ la gestione delle eccezioni è accompagnata da un meccanismo di stack unwinding — distruzione automatica (destrutturazione) degli oggetti locali nello stack delle chiamate creati prima dell'insorgere dell'eccezione. Questo fenomeno è importante per garantire il corretto rilascio delle risorse.

Storia della domanda

Inizialmente, nella progettazione di C++, manca un garbage collector integrato, e il compito di liberare le risorse (memoria, file, socket) ricade sul programmatore. La gestione delle eccezioni doveva garantire il corretto rilascio durante il rollback del codice a causa di un errore.

Problema

Senza il meccanismo di distruzione automatica degli oggetti in caso di eccezione si verificano perdite di risorse. Se non si liberano le risorse manualmente in ogni blocco catch, il codice diventa complesso e inaffidabile.

Soluzione

C++ implementa lo stack unwinding, quando, in seguito al lancio di un'eccezione, tutti gli oggetti allocati nello stack nell'ambito di visibilità prima del throw vengono distrutti nell'ordine inverso della loro creazione. I loro distruttori vengono chiamati automaticamente.

Il modo classico per liberare continuamente le risorse è applicare il pattern RAII (Resource Acquisition Is Initialization): tutte le risorse sono "avvolte" in oggetti che liberano la risorsa in loro possesso alla distruzione.

Esempio di codice:

#include <iostream>
#include <stdexcept>

struct FileHandle {
    FILE* file;
    FileHandle(const char* path) {
        file = fopen(path, "r");
        if (!file) throw std::runtime_error("Cannot open file");
    }
    ~FileHandle() {
        if (file) fclose(file);
    }
};

void processFile(const char* path) {
    FileHandle fh(path); // Ritorna se viene lanciato un throw
    // ... lavoro con il file
    throw std::runtime_error("Some error");
    // fclose verrà chiamato automaticamente
}

Caratteristiche chiave:

• Lo stack unwinding chiama automaticamente i distruttori di tutti gli oggetti nello stack.
• RAII garantisce il rilascio delle risorse indipendentemente dall'insorgere dell'eccezione.
• Il rilascio manuale delle risorse nel catch è raramente necessario: i distruttori fanno meglio.

Domande trabocchetto.

Perché non si può semplicemente usare try-catch e chiamare manualmente delete o fclose nel blocco catch per evitare perdite?

Risposta:

È scomodo e inaffidabile: è facile dimenticare di chiudere una risorsa, soprattutto con molteplici punti di uscita o risorse annidate. I distruttori vengono chiamati anche se l'eccezione "passa" attraverso la funzione, il catch non è necessario.

Gli oggetti nella heap saranno distrutti se non "avvolti" in oggetti nello stack durante lo stack unwinding?

Risposta:

No. Lo stack unwinding chiama i distruttori solo per gli oggetti allocati nello stack. Affinché gli oggetti nella heap vengano distrutti correttamente, devono essere posseduti da un oggetto nello stack (ad esempio, tramite smart pointers).

Cosa succede se un distruttore durante lo stack unwinding lancia a sua volta un'eccezione?

Risposta:

Se durante lo stack unwinding, mentre viene distrutto un oggetto, viene lanciata una seconda eccezione, il programma terminerà chiamando std::terminate(). Non lanciare mai eccezioni dai distruttori!

Errori tipici e anti-pattern

• Non liberare le risorse nei distruttori, facendo affidamento solo sulla gestione manuale nel catch.
• Lanciare eccezioni dai distruttori.
• Non utilizzare smart pointers per gestire le risorse nella heap.
• Dimenticare risorse annidate (ad esempio, un file all'interno di una struttura).

Esempio dalla vita reale

Caso negativo

Uno sviluppatore chiude manualmente i file e libera la memoria tramite blocchi catch senza applicare RAII.

Vantaggi:

• Gestisce esplicitamente le risorse.

Svantaggi:

• In caso di uscita tramite throw prima del catch, le perdite sono inevitabili.
• È difficile mantenere e modificare il codice, facile dimenticare il rilascio.

Caso positivo

File e risorse sono avvolti in classi di wrapping RAII. Risultato: il rilascio avviene nei distruttori, indipendentemente da throw/catch.

Vantaggi:

• Affidabilità nel rilascio delle risorse.
• Meno codice, facile da mantenere.

Svantaggi:

• È necessario saper scrivere wrapper RAII.
• L'aggiunta di nuovi tipi di risorse richiede nuove classi.