2013-04-26 12 views
7

Niedawno w moim kodzie wyraźnie pisałem noexcept(false) o funkcjach, o których wiem, że wyrzucają wyjątki, głównie dla osób czytających kod. Zastanawiam się jednak, czy ma to wpływ na zachowanie mojego kodu lub sposób, w jaki kompilator je interpretuje. Czy to ma jakieś znaczenie?Czy dodanie `noexcept (false)` w jakikolwiek sposób przynosi korzyść kodowi?

Uwaga: Jestem świadomy, że destruktory nie są domyślnie wyjątkiem i że musisz zmienić noexcept(false), zastanawiam się nad innymi funkcjami.

Odpowiedz

10

O bez wyjątku-specyfikator i wyraźnie zaznacza noexcept(false) odpowiadają patrz §15.4/12:

funkcję bez wyjątku specyfikacji lub z wyjątku specyfikacji postaci noexcept(constant-expression) gdzie stałej ekspresji plony false zezwalają na wszystkie wyjątki.

Kompilator nie powinien więc rozróżniać tych wyjątków.


Co ważniejsze, nie ma potrzeby, aby być sklejaniu na noexcept(false) do swoich funkcji. Jako programista w C++ powinieneś założyć domyślnie, że każda funkcja jest domyślnie wyrzucana (dlatego standard przyjmuje taką postawę), więc nie dodajesz żadnych nowych informacji, pisząc; dla wszystkich to strata czasu.

Raczej zrobić znak szczególny przypadek, gdy funkcja zdecydowanie nie wyrzuca z noexcept i zaznaczamy przypadki, w których funkcja może rzut zależności od jakiegoś warunku z noexcept(condition).

Jeśli twoja funkcja jest celowo źródłem jakiegoś wyjątku E, napisz to w swojej dokumentacji.

+1

Należy zauważyć, że w C++ 11 destruktory są domyślnie 'noexcept (true)'. Jeśli chcesz to zmienić, musisz dodać 'noexcept (false)'. Jednak prawie zawsze jest to zły pomysł. (Zaryzykowałbym twierdzenie, że to zawsze zły pomysł, ja tylko zabezpieczam się "prawie" na wypadek, gdybym nie był wystarczająco pomysłowy.) Ogromne pokosy kodu, w tym standardowa biblioteka, zakładają, że destruktory zawsze się udają i to jest bardzo trudne do skomponowania kodu w sposób, który można naprawić, jeśli czyszczenie może się nie powieść. W wielu sytuacjach jest to niemożliwe (na przykład statyczna inicjalizacja lub wielu członków klasy). –

+1

możesz użyć '/ * noexcept (false) * /', aby zasygnalizować, że nie zapomniałeś przypadkowo dodać 'noexcept' do interfejsu – TemplateRex

+1

Chciałbym mieć sposób na zaznaczenie funkcji, która może rzucić nawet, jeśli kompilator może ustalić za pomocą analizy interpre- dycyjnej, której nie jest w stanie wyrzucić. – kchoi

-1

W książce More Exceptional C++, Herb Sutter ma następujący fragment (str 130).:

Prawo odpowiedź na przykładzie 19-1 jest znacznie prostsza:

// Example 19-4: The right solution 
// 
T::~T() /* throw() */ 
{ 
// ... code that won't throw ... 
} 

Przykład 19-4 pokazuje, jak podjąć decyzję projektową zamiast gofrować.

Należy pamiętać, że specyfikacja throws-nothing exception jest tylko komentarzem. To jest styl, który wybrałem, w części , ponieważ okazuje się, że specyfikacje wyjątków przyznają znacznie mniej korzyści niż niż są warte. To, czy zdecydujesz się faktycznie napisać specyfikację, to kwestia gustu.

(Kopalnia nacisk)

Tak, czuję, że muszę podkreślić, że jednym z czołowych ekspertów w C++ kod wyjątku bezpieczne wydaje się być przeciwko całej koncepcji dodawania specyfikacji wyjątków dla kompilatora, aby wykorzystać (ale nadal pozostawiając go w kodzie, aby programiści rozumieli).

Pomyślałem, że może to być interesujące informacje ...

+4

'throw()' i 'noexcept (true)' różnią się dokładnie z tego powodu. Uważam to za _vital_ dla konstruktorów ruchu i przenoszę przypisania do 'noexcept (true)' i uważam cokolwiek innego za błąd. –

+0

@MooingDuck: Po przeczytaniu tego: http://herbsutter.com/2010/08/28/trip-report-august-2010-iso-c-standards-meeting/ Czuję, że jego punkt jeszcze pozostaje. Czy to prawda? – Escualo

+0

[tutaj] (http://herbsutter.com/2010/03/13/trip-report-march-2010-iso-c-standards-meeting/) and [Here] (http://www.gotw.ca /publications/mill22.htm) wspomina, że ​​'throw()' jest złe, ponieważ robi dziwne rzeczy. W zamieszczonym przez ciebie linku nie ma on zastrzeżeń do stosowania 'nothrow (true)' do całej standardowej biblioteki. –

Powiązane problemy