Antwoord.

Achtergrond:

C++ is oorspronkelijk ontworpen met een focus op prestaties, daarom gebeurt het beheer van middelen (geheugen, bestanden, stromingen, sockets) vaak handmatig. Bij het optreden van een uitzondering moeten de vastgehouden middelen worden vrijgegeven. Stack unwinding is een mechanisme dat door C++ wordt gebruikt voor een correcte afsluiting van functies tijdens het genereren van een uitzondering.

Probleem:

Bij het genereren van een uitzondering verschuift de controle onmiddellijk naar catch-blokken, en de tussenliggende functies worden 'afgerold': hun destructors worden aangeroepen, maar expliciete aanroepen van vrijgavefuncties kunnen worden overgeslagen (bijvoorbeeld als er geen objecten worden gebruikt die middelen automatisch vrijgeven).

Oplossing:

In C++ moet het vrijgeven van middelen aan destructors worden toevertrouwd, en niet handmatig worden aangeroepen. Het RAII (Resource Acquisition Is Initialization) patroon is een eenduidige manier om het vrijgeven van middelen automatisch te maken. Tijdens stack unwinding wordt de destructor aangeroepen en worden middelen vrijgegeven, ongeacht het pad van de functie-uitgang.

Voorbeeldcode:

#include <fstream>
#include <stdexcept>

void readFile(const std::string& filename) {
    std::ifstream file(filename); // Wordt geopend en correct gesloten, zelfs bij een uitzondering
    if (!file.is_open()) {
        throw std::runtime_error("Bestand kan niet worden geopend");
    }
    // ... lees bestand
} // file wordt zelfs bij een uitzondering gesloten

Belangrijkste kenmerken:

Stack unwinding is een standaard mechanisme voor het vernietigen van objecten bij het genereren van een uitzondering.
Zorg er altijd voor dat middelen in destructors worden vrijgegeven.
Gebruik RAII of standaard klassen (bijvoorbeeld slimme pointers).

Valstrik-vragen.

Als de code delete ptr; bevat in het catch-blok, is dat voldoende om het geheugen schoon te maken?

Nee, als er een uitzondering optreedt tussen het toewijzen van het geheugen en het catch-blok, kan het geheugen niet worden schoongemaakt. Het is beter om std::unique_ptr te gebruiken of delete in de destructor te schrijven.

Voorbeeldcode:

void foo() {
    int* data = new int[10];
    // ...
    throw std::runtime_error("fail");
    delete[] data; // wordt niet aangeroepen bij uitzondering
}

Kan stack unwinding de aanroep van de destructor voor een object op de stack overslaan?

Nee, alle lokale objecten (die niet zijn vernietigd tot het punt van uitzondering) zullen in de omgekeerde volgorde van creatie worden vernietigd, destructors zullen gegarandeerd worden aangeroepen.

Kan ik goto of longjmp gebruiken om uit een try-blok te ontsnappen en rekenen op het aanroepen van destructors?

Nee. C++ garandeert de aanroep van destructors alleen tijdens stack unwinding door een uitzondering, en niet door onjuiste sturing van de flow (goto, setjmp/longjmp).

Veelvoorkomende fouten en anti-patronen

Handmatig middelen vrijgeven binnen try-catch, waardoor destructors worden genegeerd
Ruwe pointers gebruiken in plaats van RAII of standaard klassen
Uitzonderingsafhandeling abstraheren zodanig dat middelen niet worden vrijgegeven (bijvoorbeeld setjmp/longjmp)

Voorbeeld uit het leven

Negatieve case

Een programmeur wijst geheugen toe met new, behandelt uitzonderingen door geheugen vrij te geven in het catch-blok, maar vergeet andere uitgangspaden uit de functie.

Voordelen:

Lijkt in het begin eenvoudig en "doorzichtig"

Nadelen:

Als de uitzondering wordt gegenereerd op een onverwachte plaats, ontstaat er een geheugenlek
Moeilijk te testen en te onderhouden

Positieve case

Std::unique_ptr en RAII-classes worden gebruikt voor alle middelen, vrijgave is onafhankelijk van try/catch.