Скотт Мейерс - Эффективный и современный С++. 42 рекомендации по использованию С++11 и С++14

Некоторые функции, однако, имеют естественные реализации, которые не генерируют никаких исключений, а еще некоторое их количество (в основном операции перемещения и обмена), будучи noexcept, могут дать столь значительный выигрыш, что их стоит реализовывать как noexcept, насколько это возможно [8] В спецификациях интерфейса для операций перемещения в контейнерах стандартной библиотеки noexcept отсутствует. Однако разработчикам разрешено усиливать спецификации интерфейсов функций стандартной библиотеки, и на практике как минимум для некоторых контейнеров операции перемещения объявляются как noexcept . Эта практика является примером следования совету из данного раздела. Обнаружив, что можно написать операции перемещения так, что исключения гарантированно не будут генерироваться, разработчики часто объявляют такие операции как noexcept , несмотря на то что стандарт языка от них этого не требует. . Когда вы можете уверенно сказать, что за пределы функции не должно выйти ни одно исключение, вы, определенно, должны объявить ее как noexcept.

Пожалуйста, обратите внимание на мои слова о том, что некоторые функции имеют естественную реализацию noexcept. Изменение реализации функции только для того, чтобы объявить ее как noexcept, — это хвост, виляющий собакой. Это телега перед лошадью. Это неумение увидеть лес за деревьями. Впрочем, довольно метафор. Если простая реализация функции может приводить к исключениям (например, путем вызова функции, которая может сгенерировать исключение), то попытка скрыть это исключение от вызывающего кода (например, перехватывая все исключения и заменяя их кодами состояния или специальными возвращаемыми значениями) усложнит не только реализацию вашей функции, но обычно и код в точке вызова. Например, вызывающая функция, как может оказаться, должна проверять код состояния или наличие специальных возвращаемых значений. Стоимость времени выполнения таких усложнений (например, дополнительных ветвлений, вызовов функций, которые будут влиять на кеши команд, и т.п.) легко может превысить ускорение, которое вы надеялись получить благодаря noexcept; кроме того, такой исходный код труднее понимать и поддерживать. Ничего хорошего из этого не получается.

Для некоторых функций отсутствие исключений настолько важно, что они являются noexceptпо умолчанию. В С++98 считается плохим стилем разрешать генерировать исключения функциям освобождения памяти (т.e. операторам operator deleteи operator delete[]) и деструкторам, а в C++11 это правило стиля стало правилом языка. По умолчанию все функции освобождения памяти и все деструкторы — как пользовательские, так и генерируемые компиляторами — неявно являются noexcept. Поэтому необходимости явно объявлять их таковыми нет. (Это ничему не повредит, это просто необычно.) Единственная ситуация, когда деструктор не является неявно объявленным как noexcept, — это когда член-данные класса (включая унаследованные члены и содержащиеся внутри других членов-данных) имеет тип, который явно указывает, что его деструктор может генерировать исключения (например, объявленный как noexcept(false)). Такие деструкторы являются редкостью. Их нет в стандартной библиотеке, и если деструктор объекта, используемого стандартной библиотекой (например, как элемент контейнера или переданный алгоритму аргумент), генерирует исключение, поведение программы является неопределенным.

Стоит отметить, что некоторые проектировщики библиотечных интерфейсов различают функции с широкими контрактами от функций с узкими контрактами . Функция с широким контрактом не имеет предусловий. Такая функция может быть вызвана независимо от состояния программы и не накладывает никаких ограничений на аргументы, передаваемые ей вызывающим кодом [9] “Независимо от состояния программы” и “без ограничений” не узаконивает программы, поведение которых уже является неопределенным. Например, std::vector::size имеет широкий контракт, но это не означает, что данная функция должна разумно себя вести при применении к произвольному блоку памяти, приведенному к типу std::vector . Результат приведения не определен, поэтому нет никаких гарантий, касающихся поведения программы, содержащей такое приведение. . Функции с широким контрактом никогда не демонстрируют неопределенного поведения.

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

Если вы пишете функцию с широким контрактом и знаете, что ее не покинут никакие исключения, легко следовать совету из данного раздела и объявить ее как noexcept. Для функций с узкими контрактами ситуация сложнее. Предположим, например, что вы пишете функцию f, принимающую параметр std::string, и пусть естественная реализация fникогда не генерирует исключений. Это предполагает, что функция fдолжна быть объявлена как noexcept.

Предположим теперь, что fимеет предусловие: длина ее строкового параметра std::stringне должна превышать 32 символа. Если fвызывается со строкой std::string, длина которой больше 32 символов, поведение будет неопределенным, поскольку нарушение предусловия по определению приводит к неопределенному поведению. Функция fне обязана проверять это предусловие, так как функции могут считать свои предусловия выполненными. (За обеспечение выполнения таких предположений отвечает вызывающий код.) Тогда даже при наличии предусловия объявление fкак noexceptвыглядит целесообразным:

void f(const std::string& s) noexcept; // Предусловие:

// s.length() <= 32

Но предположим, что разработчик fрешил проверять нарушения предусловия. Такая проверка не обязательна, но она и не запрещена; более того, проверка предусловия может быть полезной, например, в процессе системного тестирования. Отладка сгенерированного исключения в общем случае проще, чем попытки отследить причину неопределенного поведения. Но как следует сообщать о нарушении предусловий, чтобы проверки (или клиентский обработчик ошибок) могли его обнаружить? Простейший подход — генерация исключения “предусловие нарушено”, но если fобъявлена как noexcept, это может быть невозможным; генерация исключения приведет к завершению программы. По этой причине разработчики библиотек, различающие широкие и узкие контракты, в общем случае резервируют noexceptдля функций с широкими контрактами.

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