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

Пожалуйста, обратите внимание на мои слова о том, что некоторые функции имеют естественную реализацию 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выглядит целесообразным: