Czy powinienem używać specyfikatora wyjątku w C ++?

W C ++ można określić, że funkcja może, ale nie musi, zgłaszać wyjątek przy użyciu specyfikatora wyjątku. Na przykład:

void foo() throw(); // guaranteed not to throw an exception
void bar() throw(int); // may throw an exception of type int
void baz() throw(...); // may throw an exception of some unspecified type

Wątpię, czy faktycznie ich używam z następujących powodów:

1. Kompilator tak naprawdę nie narzuca specyfikatorów wyjątków w żaden rygorystyczny sposób, więc korzyści nie są duże. Idealnie byłoby, gdybyś chciał otrzymać błąd kompilacji.
2. Jeśli funkcja narusza specyfikator wyjątku, myślę, że standardowym zachowaniem jest zakończenie programu.
3. W VS.Net traktuje rzut (X) jako rzut (...), więc trzymanie się standardu nie jest mocne.

Czy uważasz, że należy używać specyfikatorów wyjątków?
Odpowiedz „tak” lub „nie” i podaj powody uzasadniające odpowiedź.

Nie.

Oto kilka przykładów, dlaczego:

1. Nie można zapisać kodu szablonu ze specyfikacjami wyjątków,

   template<class T>
   void f( T k )
   {
        T x( k );
        x.x();
   }

   Kopie mogą zostać rzucone, przekazanie parametru może zgłosić i x()może zgłosić nieznany wyjątek.

2. Specyfikacje wyjątków zwykle zabraniają rozszerzalności.

   virtual void open() throw( FileNotFound );

   może ewoluować w

   virtual void open() throw( FileNotFound, SocketNotReady, InterprocessObjectNotImplemented, HardwareUnresponsive );

   Naprawdę możesz to napisać jako

   throw( ... )

   Pierwsza nie jest rozszerzalna, druga jest zbyt ambitna, a trzecia jest naprawdę tym, co masz na myśli, pisząc funkcje wirtualne.

3. Starszy kod

   Kiedy piszesz kod, który opiera się na innej bibliotece, tak naprawdę nie wiesz, co może zrobić, gdy coś pójdzie nie tak.

   int lib_f();
   
   void g() throw( k_too_small_exception )
   { 
      int k = lib_f();
      if( k < 0 ) throw k_too_small_exception();
   }

   gkończy się, gdy lib_f()rzuca. To (w większości przypadków) nie jest to, czego naprawdę chcesz. std::terminate()nigdy nie należy nazywać. Zawsze lepiej jest pozwolić aplikacji zawiesić się z nieobsługiwanym wyjątkiem, z którego można pobrać ślad stosu, niż cicho / gwałtownie umrzeć.

4. Napisz kod, który zwraca typowe błędy i wyrzuca w wyjątkowych sytuacjach.

   Error e = open( "bla.txt" );
   if( e == FileNotFound )
       MessageUser( "File bla.txt not found" );
   if( e == AccessDenied )
       MessageUser( "Failed to open bla.txt, because we don't have read rights ..." );
   if( e != Success )
       MessageUser( "Failed due to some other error, error code = " + itoa( e ) );
   
   try
   {
      std::vector<TObj> k( 1000 );
      // ...
   }
   catch( const bad_alloc& b )
   { 
      MessageUser( "out of memory, exiting process" );
      throw;
   }

Niemniej jednak, gdy Twoja biblioteka po prostu zgłasza własne wyjątki, możesz użyć specyfikacji wyjątków, aby określić swój zamiar.

Unikaj specyfikacji wyjątków w C ++. Powody, które podajesz w swoim pytaniu, to całkiem dobry początek.

Zobacz „Pragmatic Look at Exception Specifications” Herba Suttera .

Wydaje mi się, że standardowo poza konwencją (dla C ++)
specyfikatory wyjątków były eksperymentem w standardzie C ++, który w większości się nie powiódł.
Wyjątkiem jest to, że specyfikator no throw jest przydatny, ale należy również wewnętrznie dodać odpowiedni blok try catch, aby upewnić się, że kod pasuje do specyfikatora. Herb Sutter ma stronę na ten temat. Gniew 82

Dodatkowo myślę, że warto opisać Gwarancje Wyjątków.

Są to w zasadzie dokumentacja opisująca, w jaki sposób na stan obiektu wpływają wyjątki uciekające przed metodą na tym obiekcie. Niestety, kompilator nie wymusza ich ani nie wspomina o nich w inny sposób.
Wzmocnienie i wyjątki

Gwarancje wyjątków

Bez gwarancji:

Nie ma gwarancji co do stanu obiektu po wyjściu wyjątku z metody
W takich sytuacjach obiekt nie powinien być dłużej używany.

Gwarancja podstawowa:

W prawie wszystkich sytuacjach powinna to być minimalna gwarancja, jaką zapewnia metoda.
Gwarantuje to, że stan obiektu jest dobrze zdefiniowany i nadal można go używać konsekwentnie.

Silna gwarancja: (inaczej gwarancja transakcyjna)

Gwarantuje to, że metoda zakończy się pomyślnie
lub zostanie zgłoszony wyjątek, a stan obiektów nie ulegnie zmianie.

Gwarancja braku rzutu:

Metoda gwarantuje, że żadne wyjątki nie będą propagowane z metody.
Wszystkie destruktory powinny dawać taką gwarancję.
| Uwaga: jeśli wyjątek ucieka przed destruktorem, podczas gdy wyjątek jest już propagowany
| aplikacja zostanie zakończona

gcc będzie emitować ostrzeżenia, gdy naruszysz specyfikacje wyjątków. To, co robię, to używać makr do używania specyfikacji wyjątków tylko w trybie "lint", kompilując się wyraźnie w celu sprawdzenia, czy wyjątki są zgodne z moją dokumentacją.

Jedynym użytecznym specyfikatorem wyjątku jest „throw ()”, na przykład „nie rzuca”.

Specyfikacje wyjątków nie są cudownie użytecznymi narzędziami w C ++. Jednak jest / jest / dobry dla nich użytek, jeśli połączymy je z std :: nieoczekiwany.

To, co robię w niektórych projektach, to kod ze specyfikacjami wyjątków, a następnie wywołanie metody set_uknown () z funkcją, która wyrzuci specjalny wyjątek mojego własnego projektu. Ten wyjątek, po skonstruowaniu, pobiera ślad wsteczny (w sposób specyficzny dla platformy) i pochodzi z std :: bad_exception (aby umożliwić propagację w razie potrzeby). Jeśli wywołuje wywołanie terminate (), jak to zwykle bywa, ślad wstecz jest wypisywany przez what () (jak również oryginalny wyjątek, który go spowodował; nie jest to trudne do znalezienia), więc otrzymuję informacje o tym, gdzie znajdował się mój kontrakt naruszony, na przykład zgłoszony nieoczekiwany wyjątek biblioteki.

Jeśli to zrobię, nigdy nie zezwalam na propagację wyjątków bibliotek (z wyjątkiem tych std) i wyprowadzam wszystkie moje wyjątki z std :: wyjątek. Jeśli biblioteka zdecyduje się rzucić, złapię i przekonwertuję na swoją własną hierarchię, pozwalając mi zawsze kontrolować kod. Funkcje oparte na szablonach, które wywołują funkcje zależne, powinny unikać specyfikacji wyjątków z oczywistych powodów; ale i tak rzadko zdarza się mieć interfejs funkcji oparty na szablonach z kodem biblioteki (a kilka bibliotek naprawdę używa szablonów w użyteczny sposób).

Jeśli piszesz kod, który będzie używany przez ludzi, którzy woleliby przyjrzeć się deklaracji funkcji niż jakimkolwiek komentarzom wokół niej, wówczas specyfikacja powie im, które wyjątki mogą chcieć przechwycić.

W przeciwnym razie nie uważam za szczególnie przydatne używanie czegokolwiek poza throw()wskazaniem, że nie zgłasza żadnych wyjątków.

Nie. Jeśli ich użyjesz i zostanie wyrzucony wyjątek, którego nie określiłeś, ani przez swój kod, ani przez kod wywoływany przez Twój kod, wtedy domyślnym zachowaniem jest natychmiastowe zakończenie programu.

Uważam również, że ich użycie zostało uznane za przestarzałe w aktualnych wersjach standardu C ++ 0x.

Specyfikacja „throw ()” umożliwia kompilatorowi wykonanie pewnych optymalizacji podczas wykonywania analizy przepływu kodu, jeśli wie, że funkcja nigdy nie zgłosi wyjątku (lub przynajmniej obiecuje, że nigdy nie zgłosi wyjątku). Larry Osterman mówi o tym krótko tutaj:

http://blogs.msdn.com/larryosterman/archive/2006/03/22/558390.aspx

Generalnie nie użyłbym specyfikatorów wyjątków. Jednak w przypadkach, gdy jakikolwiek inny wyjątek miałby pochodzić od danej funkcji, program ostatecznie nie byłby w stanie skorygować , może być przydatny. We wszystkich przypadkach upewnij się, że jasno udokumentowałeś, jakich wyjątków można oczekiwać od tej funkcji.

Tak, oczekiwanym zachowaniem niewyszczególnionego wyjątku generowanego przez funkcję ze specyfikatorami wyjątków jest wywołanie terminate ().

Zwrócę również uwagę, że Scott Meyers porusza ten temat w bardziej efektywnym języku C ++. Jego efektywne C ++ i bardziej efektywne C ++ są wysoce polecanymi książkami.

Tak, jeśli interesujesz się wewnętrzną dokumentacją. A może napisanie biblioteki, z której będą korzystać inni, aby mogli powiedzieć, co się stanie, bez zapoznania się z dokumentacją. Rzucanie lub nie wyrzucanie można uznać za część interfejsu API, prawie jak wartość zwracana.

Zgadzam się, nie są one tak naprawdę przydatne do wymuszania poprawności stylu Java w kompilatorze, ale jest lepsze niż nic lub przypadkowe komentarze.

Mogą być przydatne do testowania jednostkowego, aby podczas pisania testów wiedzieć, czego oczekiwać, że funkcja wyrzuci, gdy się nie powiedzie, ale nie ma ich wymuszania w kompilatorze. Myślę, że to dodatkowy kod, który nie jest potrzebny w C ++. Zawsze wybierasz wszystko, czego powinieneś być pewien, to przestrzeganie tego samego standardu kodowania w całym projekcie i członkach zespołu, dzięki czemu kod pozostaje czytelny.

Z artykułu:

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

„Powszechnie wiadomo, że nie jest możliwe napisanie bezpiecznego kontenera ogólnego”. Twierdzenie to jest często słyszane w odniesieniu do artykułu Toma Cargilla [4], w którym bada on problem bezpieczeństwa wyjątków dla ogólnego szablonu stosu. W swoim artykule firma Cargill stawia wiele przydatnych pytań, ale niestety nie przedstawia rozwiązania swojego problemu1. Na zakończenie sugeruje, że rozwiązanie może nie być możliwe. Niestety, wielu czytało jego artykuł jako „dowód” na te spekulacje. Odkąd został opublikowany, pojawiło się wiele przykładów bezpiecznych dla wyjątków komponentów ogólnych, między innymi kontenerów bibliotek standardowych C ++.

I rzeczywiście, mogę wymyślić sposoby uczynienia wyjątków klas szablonów bezpiecznymi. Jeśli nie masz kontroli nad wszystkimi podklasami, i tak możesz mieć problem. Aby to zrobić, można utworzyć w klasach typedefs, które definiują wyjątki wyrzucane przez różne klasy szablonów. Uważam, że problem polega na tym, że jak zwykle rozwiążemy to później, w przeciwieństwie do projektowania od samego początku, i myślę, że to ten koszt jest prawdziwą przeszkodą.

Specyfikacje wyjątków = bzdury, zapytaj dowolnego programistę Java w wieku powyżej 30 lat