Wyjątek w destruktorze

Question

W moim destruktorze muszę wyczyścić kilka zasobów. Powiedzmy, że mam trzy połączenia, aby wyczyścić zasoby, które mogą rzucić. Ponieważ nie jest dobrze, aby pozwolić wyjątkowi na opuszczenie destruktora, jaki powinien być mój wzorzec projektowy? Podobno droga poniżej nie jest skalowalna.

Dzięki.

class B::~B(){ 

try{ 
    clearResourceA() 
} 
catch{ 
    try{ 
     clearResourceB(); 
     } 
    catch{ 
     clearResourceC(); 
    } 
    clearResourceC(); 
} 
clearResourceB(); 
    . 
    . 
} 

Answer 1

Przechwytywanie wszystko, co może rzucać w destructor z catch-all (tj catch (...)) i jak najlepiej obsłużyć wyjątki rzucane. Upewnij się, że żadne wyjątki nie rozprzestrzeniają się z destruktora, co pomaga w zapobieganiu.

Answer 2

Dlaczego nie:

try{clearResourceA();} catch(...){} 
try{clearResourceB();} catch(...){} 
try{clearResourceC();} catch(...){} 

Answer 3

try 
{ 
    ClearResourceA(); 
} 
catch(...) 
{ 
    ExceptionWasThrown(); 
} 
try 
{ 
    ClearResourceB(); 
} 
catch(...) 
{ 
    ExceptionWasThrown(); 
} 
... 

Answer 4

Kapsułkować każdy zasób w klasie, który podaje je w swoim destructor (z okolic try/catch):

struct ProperlyManagedA { 
    // some means of using the resource - a rudimentary way is this: 
    A &getA() { return a; } 
    const A &getA() const { return a; } 
    // cleanup 
    ~ProperlyManagedA() { 
     try { 
      a.clear(); // whatever it is ClearResourceA actually does 
     } catch (...) {} 
    } 
    private: 
    A a; 
} 

shared_ptr z niestandardowych deleter jest jednym ze sposobów osiągnięcia tego bez konieczności tworzenia całej klasy dla każdego rodzaju zasobów.

Możesz odrzucić wyjątek (np. Zareagować na problem) w zależności od tego, co zostało wygenerowane.

Zmodyfikuj zasoby A, B i C tak, aby oczyszczały się z własnych destruktorów. To może nie być możliwe.

Tak czy inaczej, możesz umieścić tyle zasobów w jednej klasie, ile chcesz, bez dodawania żadnego kodu do destruktora klasy. To jest "skalowalność". Cały punkt RAII polega na tym, że każdy użytkownik zasobu nie powinien zapisywać kodu oczyszczającego, aby prawidłowo używać zasobu.

Answer 5

Można również zawijać swoje funkcje ClearResources, aby upewnić się, że nigdy nie rzucają. Dlaczego i tak mogą wyrzucić?

Answer 6

Ponieważ pytasz o wzór wzór Powiem, z jakiej zasady używam z powodzeniem. Wszystkie funkcje, które mają funkcję czyszczenia/zakańczania, powinny odrzucić NIGDY.

Funkcje te są zwykle dobrze znane nazwy:

• Przezroczysty *()
• Clean *()
• Zakończyć *()
• Destroy *()
• Release *()
• Odłącz *()
• Bezpłatnie *()
• Erase *()
• ~ Destructor()
• ...

Uzasadnieniem który stoi za to, że:

• musi przez co najmniej 1 zasób funkcji za które gwarancje że specyficzny zasób jest wyczyszczone
• (rekurencyjnie), jeśli budować czyste- i zwolnij wiele zasobów, a następnie używaj tylko funkcji, które gwarantują , że te zasoby zostaną zwolnione w wyjątkowy sposób
• programistów używających yo ur kod musi mieć drogę do oczyszczania zasobów
• jeśli eksportować funkcje porządkowe na zewnątrz biblioteki to nie propagować wyjątek (ponieważ użytkownicy biblioteki nie będą wiedzieć, czy zasób jest zwolniony)

And I można spróbować użyć RAII pattern. Ale nawet w tym przypadku powyższe zasady będą w użyciu.