Dlaczego w C ++ nie ma konstrukcji „nareszcie”?

Obsługa wyjątków w C ++ jest ograniczona do try / throw / catch. W przeciwieństwie do Object Pascal, Java, C # i Python, nawet w C ++ 11 finallykonstrukcja nie została zaimplementowana.

Widziałem okropnie dużo literatury C ++ omawiającej „bezpieczny kod wyjątku”. Lippman pisze, że bezpieczny kod wyjątku jest ważnym, ale zaawansowanym, trudnym tematem, wykraczającym poza zakres jego Primer - co wydaje się sugerować, że bezpieczny kod nie jest fundamentalny dla C ++. Herb Sutter poświęca temu tematowi 10 rozdziałów w swoim wyjątkowym C ++!

Wydaje mi się jednak, że wiele problemów napotkanych podczas próby napisania „kodu bezpiecznego wyjątku” można by całkiem dobrze rozwiązać, gdyby finallykonstrukcja została zaimplementowana, co pozwala programiście zapewnić, że nawet w przypadku wyjątku program będzie można przywrócić do bezpiecznego, stabilnego i szczelnego stanu, blisko punktu alokacji zasobów i potencjalnie problematycznego kodu. Jako bardzo doświadczony programista Delphi i C # używam try .. wreszcie dość obszernie blokuje mój kod, podobnie jak większość programistów w tych językach.

Biorąc pod uwagę wszystkie „dzwonki i gwizdki” zaimplementowane w C ++ 11, zdziwiłem się, widząc, że „w końcu” nadal tam nie było.

Dlaczego więc finallykonstrukcja nigdy nie została zaimplementowana w C ++? To naprawdę nie jest bardzo trudna ani zaawansowana koncepcja do zrozumienia i bardzo pomaga w pisaniu „wyjątkowego bezpiecznego kodu”.

Jako dodatkowy komentarz do odpowiedzi @ Nemanja (która, cytując Stroustrupa, naprawdę jest tak dobrą odpowiedzią, jak to tylko możliwe):

To naprawdę tylko kwestia zrozumienia filozofii i idiomów C ++. Weźmy przykład operacji, która otwiera połączenie z bazą danych trwałej klasy i musi upewnić się, że to połączenie zostanie zamknięte, jeśli zostanie zgłoszony wyjątek. Jest to kwestia bezpieczeństwa wyjątków i dotyczy dowolnego języka z wyjątkami (C ++, C #, Delphi ...).

W języku używającym try/ finallykod może wyglądać mniej więcej tak:

database.Open();
try {
    database.DoRiskyOperation();
} finally {
    database.Close();
}

Prosty i bezpośredni. Istnieje jednak kilka wad:

• Jeśli język nie ma deterministycznych destruktorów, zawsze muszę napisać finallyblok, w przeciwnym razie wycieknie zasoby.
• Jeśli DoRiskyOperationjest więcej niż jedno wywołanie metody - jeśli mam trochę przetwarzania do wykonania w trybloku - wtedy Closeoperacja może skończyć się całkiem daleko od Openoperacji. Nie mogę napisać mojego czyszczenia tuż obok mojego nabycia.
• Jeśli mam kilka zasobów, które muszą zostać pozyskane, a następnie uwolnione w sposób wyjątkowo bezpieczny, mogę skończyć z kilkoma warstwami głębokimi try/ finallybloków.

Podejście C ++ wygląda następująco:

ScopedDatabaseConnection scoped_connection(database);
database.DoRiskyOperation();

To całkowicie rozwiązuje wszystkie wady tego finallypodejścia. Ma kilka wad, ale są one stosunkowo niewielkie:

• Jest duża szansa, że ​​musisz sam napisać ScopedDatabaseConnectionlekcję. Jest to jednak bardzo prosta implementacja - tylko 4 lub 5 linii kodu.
• Polega ona na utworzeniu dodatkowej zmiennej lokalnej - której najwyraźniej nie jesteś fanem, na podstawie twojego komentarza o „ciągłym tworzeniu i niszczeniu klas polegających na ich destrukterach w celu oczyszczenia twojego bałaganu jest bardzo słaba” - ale dobry kompilator zoptymalizuje poza wszelką dodatkową pracą związaną z dodatkową zmienną lokalną. Dobry projekt C ++ opiera się w dużej mierze na tego rodzaju optymalizacjach.

Osobiście, biorąc pod uwagę te zalety i wady, uważam RAII za technikę o wiele bardziej preferowaną finally. Twój przebieg może się różnić.

Wreszcie, ponieważ RAII jest tak dobrze ugruntowanym idiomem w C ++, i aby uwolnić programistów od ciężaru pisania licznych Scoped...klas, istnieją biblioteki takie jak ScopeGuard i Boost.ScopeExit, które ułatwiają tego rodzaju deterministyczne porządki.

Od Dlaczego C ++ nie zapewnia konstrukcji „nareszcie”? w Bjarne Stroustrup w C ++ Style i technika FAQ :

Ponieważ C ++ obsługuje alternatywę, która jest prawie zawsze lepsza: technika „pozyskiwania zasobów to inicjalizacja” (TC ++ PL3 sekcja 14.4). Podstawową ideą jest reprezentowanie zasobu przez obiekt lokalny, aby destruktor obiektu lokalnego zwolnił zasób. W ten sposób programista nie może zapomnieć o zwolnieniu zasobu.

Powodem, dla którego C ++ nie ma, finallyjest to, że nie jest potrzebny w C ++. finallysłuży do wykonania kodu niezależnie od tego, czy wystąpił wyjątek, czy nie, który prawie zawsze jest rodzajem kodu czyszczącego. W C ++ ten kod czyszczenia powinien znajdować się w destruktorze odpowiedniej klasy, a destruktor będzie zawsze wywoływany, podobnie jak finallyblok. Idiom użycia destruktora do czyszczenia nazywa się RAII .

W społeczności C ++ może być więcej dyskusji na temat kodu „bezpiecznego dla wyjątków”, ale jest on prawie równie ważny w innych językach, które mają wyjątki. Cały sens kodu „wyjątkowego” polega na tym, aby pomyśleć o tym, w jakim stanie kod zostanie pozostawiony, jeśli wystąpi wyjątek w dowolnej z wywoływanych funkcji / metod.
W C ++ kod „wyjątkowy” jest nieco ważniejszy, ponieważ C ++ nie ma automatycznego czyszczenia pamięci, które zajmuje się obiektami, które zostały osierocone z powodu wyjątku.

Powód, dla którego wyjątek dotyczący bezpieczeństwa jest omawiany bardziej w społeczności C ++, prawdopodobnie wynika również z faktu, że w C ++ musisz być bardziej świadomy tego, co może pójść nie tak, ponieważ w języku jest mniej domyślnych sieci bezpieczeństwa.

Inni omawiali RAII jako rozwiązanie. To idealnie dobre rozwiązanie. Ale to tak naprawdę nie dotyczy tego , dlaczego nie dodali finallyrównież, ponieważ jest to bardzo pożądana rzecz. Odpowiedź na to pytanie jest bardziej fundamentalna przy projektowaniu i rozwoju C ++: zaangażowani w projektowanie C ++ zdecydowanie sprzeciwiali się wprowadzeniu funkcji projektowych, które można osiągnąć za pomocą innych funkcji bez większego zamieszania, a zwłaszcza tam, gdzie wymaga to wprowadzenia nowych słów kluczowych, które mogą spowodować niezgodność starszego kodu. Ponieważ RAII stanowi wysoce funkcjonalną alternatywę, finallya finallymimo to możesz samodzielnie tworzyć własne w C ++ 11, nie było potrzeby.

Wszystko, co musisz zrobić, to stworzyć klasę, Finallyktóra wywołuje funkcję przekazaną do konstruktora w destruktorze. Następnie możesz to zrobić:

try
{
    Finally atEnd([&] () { database.close(); });

    database.doRisky();
}

Jednak większość rodzimych programistów C ++ będzie preferować czyste obiekty RAII.

Możesz użyć wzorca „pułapki” - nawet jeśli nie chcesz używać bloku try / catch.

Umieść prosty obiekt w wymaganym zakresie. W destruktorze tego obiektu umieść swoją logikę „ostateczną”. Niezależnie od tego, kiedy stos zostanie rozwinięty, zostanie wywołany destruktor obiektu, a otrzymasz cukierki.

Cóż, możesz coś w stylu roll-your-own finally, używając Lambdas, który uzyskałby następującą kompilację (używając przykładu bez RAII, oczywiście, nie najładniejszego kodu):

{
    FILE *file = fopen("test","w");

    finally close_the_file([&]{
        cout << "We're closing the file in a pseudo-finally clause." << endl;
        fclose(file);
    });
}

Zobacz ten artykuł .

Nie jestem pewien, czy zgadzam się z twierdzeniami, że RAII jest nadzbiorem finally. Pięta achillesowa RAII jest prosta: wyjątki. RAII jest implementowane za pomocą destruktorów i w C ++ zawsze jest wyrzucanie z destruktora. Oznacza to, że nie możesz używać RAII, gdy potrzebujesz do wyczyszczenia kodu czyszczenia. finallyZ drugiej strony, gdyby zostały wdrożone, nie ma powodu, aby sądzić, że rzucanie z finallybloku byłoby niezgodne z prawem .

Rozważ taką ścieżkę kodu:

void foo() {
    try {
        ... stuff ...
        complex_cleanup();
    } catch (A& a) {
        handle_a(a);
        complex_cleanup();
        throw;
    } catch (B& b) {
        handle_b(b);
        complex_cleanup();
        throw;
    } catch (...) {
        handle_generic();
        complex_cleanup();
        throw;
    }
}

Gdybyśmy mieli finally, moglibyśmy napisać:

void foo() {
    try {
        ... stuff ...
    } catch (A& a) {
        handle_a(a);
        throw;
    } catch (B& b) {
        handle_b(b);
        throw;
    } catch (...) {
        handle_generic();
        throw;
    } finally {
        complex_cleanup();
    }
}

Ale nie mogę znaleźć równoważnego zachowania przy użyciu RAII.

Jeśli ktoś wie, jak to zrobić w C ++, jestem bardzo zainteresowany odpowiedzią. Byłbym nawet zadowolony z czegoś, na czym polegał, na przykład wymuszając, że wszystkie wyjątki odziedziczone po jednej klasie z pewnymi specjalnymi możliwościami lub czymś takim.