Следует ли использовать спецификатор исключения в C++?

Обычно я бы не стал использовать спецификаторы исключений. Однако в случаях, когда из рассматриваемой функции должно исходить какое-либо другое исключение, что программа окончательно не сможет выполнить правильный, это может быть полезно. Во всех случаях обязательно четко документируйте, каких исключений можно ожидать от этой функции.

Да, ожидаемым поведением неуказанного исключения, генерируемого функцией со спецификаторами исключения, является вызов terminate ().

Замечу также, что Скотт Мейерс рассматривает эту тему в «Более эффективном C++». Его книги «Эффективный C++» и «Более эффективный C++» очень рекомендуются.

Если вы пишете код, который будет использоваться людьми, которые предпочли бы смотреть на объявление функции, чем на какие-либо комментарии к нему, тогда спецификация сообщит им, какие исключения они могут захотеть перехватить.

В противном случае я не считаю особенно полезным использовать что-либо, кроме throw(), чтобы указать, что он не генерирует никаких исключений.

Да, если вам нужна внутренняя документация. Или, может быть, написать библиотеку, которую будут использовать другие, чтобы они могли знать, что происходит, не обращаясь к документации. Бросок или не бросание можно рассматривать как часть API, почти как возвращаемое значение.

Я согласен, они не очень полезны для обеспечения корректности стиля Java в компиляторе, но это лучше, чем ничего или случайные комментарии.

Избегайте спецификаций исключений в C++. Причины, которые вы указываете в своем вопросе, - довольно хорошее начало для объяснения того, почему.

См. «Прагматичный взгляд на спецификации исключений» Херба Саттера.

Они могут быть полезны для модульного тестирования, так что при написании тестов вы знаете, чего ожидать от функции, когда она терпит неудачу, но в компиляторе их не применяют. Я думаю, что это лишний код, который не нужен в C++. Что бы вы ни выбрали, все, в чем вы должны быть уверены, - это то, что вы следуете одному и тому же стандарту кодирования во всем проекте и для членов команды, чтобы ваш код оставался читаемым.

Нет.

Вот несколько примеров, почему:

1. Код шаблона невозможно написать с указанием исключений,

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

   Копии могут генерироваться, передача параметров может вызывать, а x() может генерировать какое-то неизвестное исключение.

2. Спецификации исключений имеют тенденцию запрещать расширяемость.

   virtual void open() throw( FileNotFound );
   

   может превратиться в

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

   Вы действительно могли бы написать это как

   throw( ... )
   

   Первое не расширяемо, второе чрезмерно амбициозно, а третье действительно то, что вы имеете в виду, когда пишете виртуальные функции.

3. Устаревший код

   Когда вы пишете код, основанный на другой библиотеке, вы действительно не знаете, что он может делать, если что-то пойдет не так.

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

   g завершится, когда lib_f() выдает ошибку. Это (в большинстве случаев) не то, что вам действительно нужно. std::terminate() никогда не должен называться. Всегда лучше позволить приложению вылететь из-за необработанного исключения, из которого вы можете получить трассировку стека, чем молча / насильственно умереть.

4. Напишите код, который возвращает типичные ошибки и выдает в исключительных случаях.

   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;
   }
   

Тем не менее, когда ваша библиотека просто генерирует ваши собственные исключения, вы можете использовать спецификации исключений, чтобы заявить о своем намерении.

gcc выдаст предупреждения, если вы нарушите спецификации исключения. Что я делаю, так это использую макросы для использования спецификаций исключений только в режиме компиляции "lint" специально для проверки, чтобы убедиться, что исключения согласуются с моей документацией.

Я думаю, что стандартно кроме соглашения (для C++)
Спецификаторы исключений были экспериментом в стандарте C++, который в большинстве случаев провалился. Исключением является то, что спецификатор no throw полезен, но вы также должны добавить соответствующий блок try catch внутри, чтобы убедиться, что код соответствует спецификатору. У Херба Саттера есть страница по этой теме. Gotch 82

В дополнение, я думаю, стоит описать гарантии исключений.

Это в основном документация о том, как на состояние объекта влияют исключения, экранирующие метод этого объекта. К сожалению, компилятор не применяет их и не упоминает иным образом. Повышение и исключения

Гарантии исключения

Нет гарантии:

There is no guarantee about the state of the object after an exception escapes a method
In these situations the object should no longer be used.

Основная гарантия:

In nearly all situations this should be the minimum guarantee a method provides.
This guarantees the object's state is well defined and can still be consistently used.

Сильная гарантия: (также известная как транзакционная гарантия)

This guarantees that the method will complete successfully
Or an Exception will be thrown and the objects state will not change.

Гарантия отсутствия броска:

The method guarantees that no exceptions are allowed to propagate out of the method.
All destructors should make this guarantee.
| N.B. If an exception escapes a destructor while an exception is already propagating
| the application will terminate

Единственный полезный спецификатор исключения - это «throw ()», как в «не выбрасывает».

Нет. Если вы их используете и генерирует исключение, которое вы не указали, либо вашим кодом, либо кодом, вызванным вашим кодом, то поведение по умолчанию - незамедлительно завершить вашу программу.

Кроме того, я считаю, что их использование устарело в текущих проектах стандарта C++ 0x.

Спецификации исключений - не очень полезные инструменты в C++. Однако для них есть / есть / хорошее применение в сочетании с std :: неожиданно.

В некоторых проектах я делаю код со спецификациями исключений, а затем вызываю set_unexpected () с функцией, которая генерирует специальное исключение моего собственного дизайна. Это исключение при построении получает обратную трассировку (в зависимости от платформы) и выводится из std :: bad_exception (чтобы разрешить его распространение при желании). Если это вызывает вызов terminate (), как это обычно бывает, трассировка распечатывается функцией what () (а также исходным исключением, вызвавшим его; это не сложно найти), и поэтому я получаю информацию о том, где был мой контракт. нарушено, например, возникло непредвиденное исключение библиотеки.

Если я сделаю это, я никогда не разрешаю распространение исключений библиотеки (кроме std) и получаю все свои исключения из std :: exception. Если библиотека решит бросить, я поймаю и конвертирую в свою собственную иерархию, что позволит мне всегда контролировать код. Шаблонные функции, вызывающие зависимые функции, должны избегать спецификаций исключений по очевидным причинам; но в любом случае редко бывает шаблонный интерфейс функции с кодом библиотеки (и несколько библиотек действительно используют шаблоны полезным образом).

Спецификации исключения = мусор, спросите любого Java-разработчика старше 30 лет.

Из статьи:

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

“It is well known to be impossible to write an exception-safe generic container.” This claim is often heard with reference to an article by Tom Cargill [4] in which he explores the problem of exception-safety for a generic stack template. In his article, Cargill raises many useful questions, but unfortunately fails to present a solution to his problem.1 He concludes by suggesting that a solution may not be possible. Unfortunately, his article was read by many as “proof” of that speculation. Since it was published there have been many examples of exception-safe generic components, among them the C++ standard library containers.

И действительно, я могу придумать способы сделать исключения шаблонных классов безопасными. Если у вас нет контроля над всеми подклассами, у вас все равно может возникнуть проблема. Для этого можно создать в своих классах определения типов, которые определяют исключения, создаваемые различными классами шаблонов. Я думаю, что проблема, как всегда, в том, чтобы решать ее впоследствии, а не проектировать ее с самого начала, и я думаю, что именно эти накладные расходы являются настоящим препятствием.

Спецификация throw () позволяет компилятору выполнять некоторые оптимизации при анализе потока кода, если он знает, что функция никогда не вызовет исключение (или, по крайней мере, обещает никогда не генерировать исключение). Ларри Остерман вкратце рассказывает об этом здесь:

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