Czy piszesz (naprawdę) bezpieczny kod wyjątku? [zamknięte]

Twoje pytanie sprawia, że stwierdzenie, że "pisanie kodu bezpiecznego dla wyjątków jest bardzo trudne". Najpierw odpowiem na twoje pytania, a potem na ukryte za nimi pytanie.

Odpowiadanie na pytania

Czy naprawdę piszesz bezpieczny kod WYJĄTKÓW?

To jest powód, dla którego Java straciła wiele swojej atrakcyjności dla mnie jako programisty C++ (Brak semantyki RAII), ale dygresję: to jest pytanie C++.

It jest, w rzeczywistości, konieczne, gdy trzeba pracować z kodem stl lub Boost. Na przykład, wątki C++ (boost::thread lub std::thread) wyrzucą wyjątek, aby zakończyć z wdziękiem.

Czy jesteś pewien, że twój ostatni kod "gotowy do produkcji" jest bezpieczny dla WYJĄTKÓW?

Czy możesz być w ogóle pewien, że tak jest?

Pisanie kodu bezpiecznego dla wyjątków jest jak pisanie kodu wolnego od błędów.

Nie możesz być w 100% pewien, że Twój kod jest bezpieczny dla WYJĄTKÓW. Ale potem dążysz do tego, używając znanych wzorców i unikanie znanych anty-wzorców.

Czy wiesz i / lub faktycznie używać alternatyw, które działają?

Nie ma realnych alternatyw w C++ (tzn. musisz wrócić do C i uniknąć bibliotek C++, a także zewnętrznych niespodzianek, takich jak Windows SEH).

Zapisywanie bezpiecznego kodu wyjątku

Aby napisać bezpieczny kod wyjątku, musisz najpierw wiedzieć jaki jest poziom bezpieczeństwa wyjątków dla każdej instrukcji, którą piszesz.

Dla na przykład, new może rzucić wyjątek, ale przypisanie wbudowanego (np. int lub wskaźnik) nie zakończy się niepowodzeniem. Swap nigdy nie zawiedzie (nigdy nie pisz swapu rzucającego), a std::list::push_back może rzucać...

Gwarancja wyjątku

1. none : Twój kod nigdy nie powinien tego oferować. Ten kod wycieknie wszystko i zepsuje się na samym początku wyjątek wyrzucony.
2. To jest gwarancja, którą musisz przynajmniej zaoferować, to znaczy, że jeśli zostanie wyrzucony wyjątek, żadne zasoby nie zostaną wycieknięte, a wszystkie obiekty są nadal w całości.]}
3. W przeciwieństwie do C++, nie jest w stanie w żaden sposób skompilować danych, ponieważ nie jest w stanie w żaden sposób skompilować danych, które nie zostały w ogóle uruchomione (co daje moc transakcyjną dla C++).]}
4. nothrow / nofail: przetwarzanie będzie / align = "left" /

Przykład kodu

void doSomething(T & t)
{
   if(std::numeric_limits<int>::max() > t.integer)  // 1.   nothrow/nofail
      t.integer += 1 ;                              // 1'.  nothrow/nofail
   X * x = new X() ;                // 2. basic : can throw with new and X constructor
   t.list.push_back(x) ;            // 3. strong : can throw
   x->doSomethingThatCanThrow() ;   // 4. basic : can throw
}

Najniższa oferowana gwarancja jest podstawowa, ale wtedy kolejność każdej instrukcji sprawia, że cała funkcja "brak", bo jeśli 3. rzuca, x przecieka.

Pierwszą rzeczą do zrobienia byłoby uczynienie funkcji "podstawową" , czyli umieszczenie x w inteligentnym wskaźniku, dopóki nie zostanie bezpiecznie własnością listy:

void doSomething(T & t)
{
   if(std::numeric_limits<int>::max() > t.integer)  // 1.   nothrow/nofail
      t.integer += 1 ;                              // 1'.  nothrow/nofail
   std::auto_ptr<X> x(new X()) ;    // 2.  basic : can throw with new and X constructor
   X * px = x.get() ;               // 2'. nothrow/nofail
   t.list.push_back(px) ;           // 3.  strong : can throw
   x.release() ;                    // 3'. nothrow/nofail
   px->doSomethingThatCanThrow() ;  // 4.  basic : can throw
}

Teraz nasz kod oferuje "podstawową" gwarancję. Nic nie wycieknie, a wszystkie obiekty będą w prawidłowym stanie. Ale możemy zaoferować więcej, czyli silną gwarancję. To jest miejsce, gdzie może stać się kosztowne, i dlatego nie wszystkie kod C++ jest silny. Spróbujmy:

void doSomething(T & t)
{
   // we create "x"
   std::auto_ptr<X> x(new X()) ;    // 1. basic : can throw with new and X constructor
   X * px = x.get() ;               // 2. nothrow/nofail
   px->doSomethingThatCanThrow() ;  // 3. basic : can throw

   // we copy the original container to avoid changing it
   T t2(t) ;                        // 4. strong : can throw with T copy-constructor

   // we put "x" in the copied container
   t2.list.push_back(px) ;          // 5. strong : can throw
   x.release() ;                    // 6. nothrow/nofail
   if(std::numeric_limits<int>::max() > t2.integer)  // 7.   nothrow/nofail
      t2.integer += 1 ;                              // 7'.  nothrow/nofail

   // we swap both containers
   t.swap(t2) ;                     // 8. nothrow/nofail
}

Ponownie uporządkowaliśmy operacje, najpierw tworząc i ustawiając X na odpowiednią wartość. Jeśli jakakolwiek operacja się nie powiedzie, to t nie jest modyfikowana, więc operacje od 1 do 3 można uznać za "silne": jeśli coś rzuca, t nie jest modyfikowana i X nie wycieka, ponieważ jest własnością inteligentnego wskaźnika.

Następnie tworzymy kopię t2 z t i pracujemy nad tą kopią od operacji 4 do 7. Jeśli coś rzuca, {[12] } jest modyfikowane, ale wtedy {[9] } jest nadal oryginałem. Nadal oferujemy silną gwarancję.

Następnie zamieniamy t i t2. Operacje swapowe nie powinny być wykonywane w C++, więc miejmy nadzieję, że Zamiana, dla której napisałeś T, jest nothrow (jeśli nie jest, przepisz ją tak, aby była nothrow).

Więc, jeśli osiągniemy koniec funkcji, wszystko się powiodło (nie ma potrzeby zwracania typu) i t ma swoją wyjątkową wartość. Jeśli się nie powiedzie, to t nadal ma swoją pierwotną wartość.

Teraz oferowanie silnej gwarancji może być dość kosztowne, więc nie staraj się oferować silnej gwarancji dla całego kodu, ale jeśli możesz to zrobić bez kosztów (i C++ inlining i inne optymalizacja może sprawić, że cały powyższy kod), następnie zrób to. Użytkownik funkcji podziękuje Ci za to.

Podsumowanie

Pisanie kodu bezpiecznego dla WYJĄTKÓW wymaga pewnego nawyku. Musisz ocenić gwarancję oferowaną przez każdą instrukcję, a następnie musisz ocenić gwarancję oferowaną przez listę instrukcji.

Oczywiście kompilator C++ nie cofnie gwarancji (w moim kodzie oferuję gwarancję jako tag @ warning doxygen), co jest trochę smutne, ale powinno nie powstrzymuje cię przed próbą napisania kodu bezpiecznego dla WYJĄTKÓW.

Normalna awaria vs. bug

Jak programista może zagwarantować, że funkcja bezawaryjna zawsze się powiedzie? W końcu funkcja może mieć błąd.

Wyjątki dotyczą wyjątkowej awarii przetwarzania, a nie błędów kodu.

Ostatnie słowa

Wtedy "podstawowy" jest najmniejszą gwarancją, którą powinieneś zaoferować. C++ jest tam bardzo silnym językiem, z jego zakresami, pozwalającymi uniknąć wycieków zasobów (coś, co Śmieciarz byłby trudny do zaoferowania dla bazy danych, połączenia lub uchwytów plików).

Więc, z tego co widzę, tojest warte to.

Edit 2010-01-29: o wymianie bez rzucania

• [ja] Zamiana nigdy nie zawiedzie (nawet nie pisz wymiany rzucającej)
• [nobar] jest to dobra rekomendacja dla niestandardowych funkcji swap(). Należy jednak zauważyć, że std::swap() może zawieść w oparciu o operacje, których używa wewnętrznie

Domyślne std::swap wykonuje kopie i zadania, które dla niektórych obiektów mogą rzucać. Tak więc, domyślna zamiana może rzucać, albo używana dla Twoich klas, albo nawet dla klas STL. Jeśli chodzi o standard C++, operacja swap dla vector, deque, i list nie rzuci, podczas gdy może dla map jeśli funktor porównawczy może rzucić na budowę kopii (Patrz język programowania C++, Wydanie Specjalne, dodatek E, E. 4. 3.Swap ).

Patrząc na implementację Visual C++ 2008 swap wektora, swap wektora nie rzuci, jeśli dwa wektory mają ten sam alokator (tj. normalny przypadek), ale zrobi kopie, jeśli mają różne alokatory. I dlatego zakładam, że może dorzucić tę ostatnią sprawę.

Tak więc oryginalny tekst nadal zawiera: nigdy nie pisz wymiany rzucającej, ale komentarz nobara musi zostać zapamiętany: upewnij się, że obiekty, które wymieniasz, mają wymianę Nie rzucającą.

Edycja 2011-11-06: ciekawy artykuł

Dave W 2007 roku, w wyniku połączenia z Internetem STL, w 2008 roku, w wyniku połączenia z Internetem STL, w 2009 roku, w wyniku połączenia z Internetem STL, w 2009 roku, w wyniku połączenia z Internetem STL, w 2009 roku, w 2009 roku, w 2009 roku]}

Http://www.boost.org/community/exception_safety.html

Spójrz na siódmy punkt (automatyczne testy dla bezpieczeństwa WYJĄTKÓW), gdzie opiera się na automatycznych testach jednostkowych, aby upewnić się, że każdy przypadek jest testowany. Myślę, że ta część jest doskonałą odpowiedzią na pytanie autora " czy możesz być nawet pewien, że to jest?".

Edit 2013-05-31: komentarz od dionadar

t.integer += 1; jest bez gwarancji, że przepełnienie nie stanie się nie wyjątek bezpieczny, a w rzeczywistości może technicznie wywołać UB! (Signed overflow to UB: C++11 5/4 "jeśli podczas oceny wyrażenia wynik nie jest zdefiniowany matematycznie lub nie mieści się w zakresie reprezentowalnych wartości dla jego typu, zachowanie jest niezdefiniowane.") Zauważ, że unsigned integer nie przepełnia się, ale wykonuje swoje obliczenia w klasie równoważności modulo 2^#bity.

   t.integer += 1 ;                 // 1. nothrow/nofail

Rozwiązaniem jest sprawdzenie, czy liczba całkowita jest już na swojej maksymalnej wartości (używając std::numeric_limits<T>::max()) przed dodaniem.

Mój błąd trafiłby do sekcji "normalna awaria a błąd", czyli błąd. Nie unieważnia to rozumowania i nie oznacza, że kod bezpieczny dla wyjątków jest bezużyteczny, ponieważ niemożliwy do osiągnięcia. Ty nie możesz zabezpieczyć się przed wyłączeniem komputera, błędami kompilatora, a nawet Twoimi błędami lub innymi błędami. Nie można osiągnąć doskonałości, ale można spróbować dostać się jak najbliżej.

Poprawiłem kod mając na uwadze komentarz Dionadara.