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

В C ++ вы можете указать, что функция может или не может генерировать исключение, используя спецификатор исключения. Например:

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

Я сомневаюсь в том, чтобы использовать их на самом деле по следующим причинам:

1. Компилятор на самом деле не применяет спецификаторы исключений каким-либо строгим образом, поэтому преимущества невелики. В идеале вы хотели бы получить ошибку компиляции.
2. Если функция нарушает спецификатор исключения, я думаю, что стандартным поведением является завершение программы.
3. В VS.Net он обрабатывает throw (X) как throw (...), поэтому соблюдение стандарта не является строгим.

Как вы думаете, следует ли использовать спецификаторы исключений?
Пожалуйста, ответьте «да» или «нет» и укажите причины, чтобы обосновать свой ответ.

Нет.

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

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

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

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

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

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

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

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

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

Без гарантии:

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

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

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

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

Это гарантирует, что метод завершится успешно. В
противном случае будет сгенерировано исключение и состояние объектов не изменится.

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

Этот метод гарантирует, что никакие исключения не могут распространяться за пределы метода.
Все деструкторы должны давать эту гарантию.
| NB Если исключение ускользает от деструктора, когда исключение уже распространяется
| приложение будет закрыто

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Из статьи:

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

«Хорошо известно, что невозможно написать безопасный универсальный контейнер». Это утверждение часто можно услышать со ссылкой на статью Тома Каргилла [4], в которой он исследует проблему безопасности исключений для универсального шаблона стека. В своей статье Каргилл поднимает много полезных вопросов, но, к сожалению, не предлагает решения своей проблемы1. В заключение он высказывает предположение, что решение может быть невозможно. К сожалению, его статья была воспринята многими как «доказательство» этого предположения. С момента его публикации появилось множество примеров безопасных в отношении исключений универсальных компонентов, в том числе контейнеров стандартной библиотеки C ++.

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

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