Wyjątki bardzo ułatwiają pisanie kodu, w którym zgłoszenie wyjątku spowoduje przerwanie niezmienników i pozostawienie obiektów w niespójnym stanie. Zasadniczo zmuszają cię do zapamiętania, że prawie każde twoje oświadczenie może potencjalnie rzucić i poprawnie sobie z tym poradzić. Może to być trudne i sprzeczne z intuicją.
Rozważ coś takiego jako prosty przykład:
class Frobber
{
int m_NumberOfFrobs;
FrobManager m_FrobManager;
public:
void Frob()
{
m_NumberOfFrobs++;
m_FrobManager.HandleFrob(new FrobObject());
}
};
Zakładając, że FrobManagerbędzie deletesię FrobObject, to wygląda OK, prawda? A może nie ... Wyobraź sobie, że albo FrobManager::HandleFrob()albo operator newrzuca wyjątek. W tym przykładzie przyrost wartości m_NumberOfFrobsnie jest wycofywany. Dlatego każdy, kto korzysta z tej instancji programu, Frobberbędzie miał prawdopodobnie uszkodzony obiekt.
Ten przykład może wydawać się głupi (ok, musiałem się trochę rozciągnąć, aby go skonstruować :-)), ale na wynos jest to, że jeśli programista nie myśli ciągle o wyjątkach i upewniając się, że każda permutacja stanu zostanie zmieniona gdy są rzuty, wpadasz w kłopoty.
Na przykład możesz o tym myśleć tak, jak o muteksach. W sekcji krytycznej polegasz na kilku instrukcjach, aby upewnić się, że struktury danych nie są uszkodzone i że inne wątki nie widzą twoich wartości pośrednich. Jeśli którekolwiek z tych stwierdzeń po prostu przypadkowo się nie powiedzie, znajdziesz się w świecie bólu. Teraz usuń blokady i współbieżność i pomyśl o każdej metodzie w ten sposób. Pomyśl o każdej metodzie jak o transakcji permutacji stanu obiektu, jeśli wolisz. Na początku wywołania metody obiekt powinien mieć stan czysty, a na końcu również stan czysty. W międzyczasie zmienna foomoże być niespójna zbar, ale twój kod w końcu to naprawi. Wyjątki oznaczają, że każde z Twoich wypowiedzi może Ci przeszkodzić w dowolnym momencie. W każdej indywidualnej metodzie spoczywa na tobie ciężar, aby to naprawić i wycofać, gdy tak się stanie, lub tak uporządkować operacje, aby rzuty nie wpływały na stan obiektu. Jeśli zrobisz to źle (i łatwo jest popełnić taki błąd), wtedy dzwoniący zobaczy Twoje wartości pośrednie.
Metody takie jak RAII, o którym programiści C ++ uwielbiają wspominać jako ostateczne rozwiązanie tego problemu, bardzo dobrze chronią przed tym problemem. Ale to nie jest srebrna kula. Zapewni to natychmiastowe zwolnienie zasobów, ale nie zwalnia cię od konieczności myślenia o uszkodzeniu stanu obiektu i wywołujących widzenie wartości pośrednich. Tak więc wielu ludziom łatwiej powiedzieć, zgodnie z zasadami stylu kodowania, bez wyjątków . Jeśli ograniczysz rodzaj pisanego kodu, trudniej będzie wprowadzić te błędy. Jeśli tego nie zrobisz, łatwo popełnić błąd.
Napisano całe książki o kodowaniu bezpiecznym dla wyjątków w C ++. Wielu ekspertów pomyliło się. Jeśli jest naprawdę tak złożony i ma tak wiele niuansów, może to dobry znak, że musisz zignorować tę funkcję. :-)