При разработке на C++ время от времени приходится писать код, в котором исключения не должны возникать. Например, когда нам нужно написать не бросающий исключений swap для собственных типов или определить noexcept move-оператор для своего класса, или вручную реализовать нетривиальный деструктор. В С++11 в язык был добавлен модификатор noexcept, который позволяет разработчику понять, что из помеченной noexcept-ом функции (или метода) исключения вылететь не могут. Поэтому функции с такой пометкой могут смело использоваться в контекстах, где исключения не должны возникать. Например, если у меня есть вот такие типы и функции: и есть некий класс resources_owner, который владеет объектами типа first_resource и second_resource: то я могу написать деструктор resources_owner следующим образом: В каком-то смысле noexcept в C++11 сделал жизнь C++ разработчика легче. Но у текущей реализации noexcept в современном C++ есть одна неприятная сторона... Допустим, что в приведенном выше примере я ошибся: почему-то посчитал, что release() помечена как noexcept, но на самом деле она таковой не является и может бросать исключения. Это означает, что когда я пишу деструктор с использованием такой бросающей release(): то я напрашиваюсь на неприятности. Рано или поздно эта release() бросит исключение и все мое приложение упадет из-за автоматически вызванного std::terminate(). Еще хуже будет, если упадет не мое приложение, а чужое, в котором использовали мою библиотеку вот с таким вот проблемным деструктором для resources_owner. Или другая вариация этой же проблемы. Допустим, что я не ошибся, что release() действительно помечена как noexcept. Была. Была помечена в версии 1.0 сторонней библиотеки из которой я взял first_resource и release(). А потом, спустя несколько лет, я обновился до версии 3.0 этой библиотеки, но в версии 3.0 у release() уже нет модификатора noexcept. Ну а что? Новая мажорная версия, запросто могли API поломать. Только вот я, скорее всего, забуду поправить реализацию деструктора resources_owner-а. А уж если вместо меня поддержкой resource_owner-а занимается кто-то другой, кто никогда в этот деструктор и не заглядывал, то изменения в сигнатуре release() наверняка останутся незамеченными. Поэтому лично мне в текущей реализации noexcept в C++ не нравится то, что компилятор никак не предупреждает программиста о том, что программист внутри noexcept метода/функции делает вызов бросающих исключения методов/функций. Было бы лучше, если бы компилятор выдавал бы такие предупреждения. OK, компилятор не выдает никаких предупреждений. И с этим простому разработчику ничего не поделать. Не заниматься же модификаций C++ компилятора под собственные нужды. Особенно если приходится пользоваться не одним компилятором, а разными версиями разных C++ компиляторов. А можно ли получить помощь от компилятора не залезая в его потроха? Т.е. можно ли самостоятельно сделать какие-то инструменты для контроля содержимого noexcept методов/функций, пусть даже дендро-фекальным способом? Можно. Коряво, но можно. Описанный в данной статье подход был опробован на практике при подготовке очередной версии нашего небольшого встраиваемого HTTP-сервера RESTinio. Дело в том, что по мере наполнения RESTinio функциональностью мы упустили из виду вопросы exception safety в нескольких местах. В частности, со временем выяснилось, что исключения иногда могут вылетать из переданных в Asio коллбэков (чего быть не должно), а также исключения, в принципе, могут вылетать и при чистке ресурсов. К счастью, на практике эти проблемы ни разу не проявились, но технический долг копился и с этим нужно было что-то делать. Причем делать нужно было что-то с кодом, который уже был написан. Т.е. работающий не-noexcept код следовало преобразовать в работающий noexcept код. Сделано это было при помощи нескольких макросов, которые были расставлены по коду в нужных местах. Например, тривиальный случай: А вот менее тривиальный фрагмент: Использование этих макросов несколько раз ударило по рукам, указав на места, которые я по недосмотру воспринимал как noexcept, но которые таковыми не были. Так что описываемый далее подход, конечно же, является самодельным лисапедом с квадратными колесами, но он ездиит… В смысле работает. Далее в статье речь пойдет уже о реализации, которая была выделена из кода RESTinio в отдельный набор макросов. Суть подхода состоит в том, чтобы передать утверждение/оператор (stmt), которое нужно проверить на noexcept, в некий макрос. Этот макрос задействует static_assert(noexcept(stmt), msg) для проверки того, что stmt действительно noexcept, после чего подставляет stmt в код. По сути, вот такое: будет заменено на что-то вроде: В принципе, можно было бы обойтись без макросов и можно было писать static_assert(noexcept(...)) прямо в коде непосредственно перед проверяемыми действиями. Но у макросов есть, по меньшей мере, пара достоинства, которые склонили чашу весов в пользу использования именно макросов. Во-первых, макросы уменьшают дублирование кода. Есть сравнить: и то видно, что с макросами основное выражение, т.е. release(some_resource) можно записать только однажды. Что уменьшает вероятность "расползания" кода со временем, при его сопровождении, когда в одном месте исправление внесли, а во втором — забыли. Во-вторых, макросы и, соответственно, спрятанные за ними проверки, можно очень легко отключить. Скажем, если обилие static_assert-ов стало негативно сказываться на скорости компиляции (хотя я такого эффекта не заметил). Или, что более существенно, при обновлении какой-нибудь сторонней библиотеки ошибки компиляции от спрятанных за макросами static_assert-ов, могут посыпаться прямо рекой. Временное отключение макросов может позволить провести плавное обновление кода, включая проверочные макросы последовательно сперва в одном файле, потом во втором, потом в третьем и т.д. Так что макросы, хоть и являются устаревшей и крайне спорной фичей в C++, в данном конкретном случае жизнь разработчику упрощают. Основной макрос ENSURE_NOEXCEPT_STATEMENT реализуется тривиально: Он применяется для проверки того, что вызываемые методы/функции действительно являются noexcept и их вызовы не нужно обрамлять блоками try-catch. Например: В дополнение есть еще и макрос ENSURE_NOT_NOEXCEPT_STATEMENT. Он применяется для того, чтобы убедиться, что требуется дополнительный блок try-catch вокруг вызова, чтобы возможные исключения не улетели наружу: К сожалению, макросы ENSURE_NOEXCEPT_STATEMENT и ENSURE_NOT_NOEXCEPT_STATEMENT могут применяться только для утверждений/операторов (statements), но не для возвращающих значение выражений (expressions). Т.е. нельзя посредством ENSURE_NOEXCEPT_STATEMENT написать так: Поэтому ENSURE_NOEXCEPT_STATEMENT не получается использовать, например, в циклах, где часто приходится писать что-то вроде: и требуется убедиться, что вызовы get_first(), get_next(), а также операции присваивания новых значений для i не бросают исключений.  Для борьбы с такими ситуациями были написаны макросы STATIC_ASSERT_NOEXCEPT и STATIC_ASSERT_NOT_NOEXCEPT, за которыми спрятаны только static_assert-ы и ничего больше. С помощью этих макросов можно достичь нужного мне результата каким-то таким образом (компилябильность именно этого фрагмента не проверялась): Очевидно, что это не есть самое лучшее решение, т.к. оно приводит к дублированию кода и повышает опасность его "расползания" при дальнейшем сопровождении. Но в качестве первого шага эти простейшие макросы оказались полезны. Когда я поделился этим опытом у себя в блоге и в Facebook-е, то поступило предложение оформить описанные выше наработки в виде отдельной библиотеки. Что и было сделано: на github-е теперь лежит малюсенькая header-only библиотека noexcept-compile-time-check (или noexcept-ctcheck, если экономить на буквах). Так что все вышеописанное можно взять и попробовать. Правда там названия макросов чуть подлинее, чем использовано в статье. Т.е. NOEXCEPT_CTCHECK_ENSURE_NOEXCEPT_STATEMENT вместо ENSURE_NOEXCEPT_STATEMENT. Есть желание сделать макрос ENSURE_NOEXCEPT_EXPRESSION, который можно было бы использовать вот так: В первом приближении он мог бы выглядеть как-то так: Но есть смутные подозрения, что здесь есть некие подводные камни, о которых я еще не задумывался. В общем, до ENSURE_NOEXCEPT_EXPRESSION руки пока не дошли :( Моя давняя мечта — это заиметь в C++ noexcept-блок, в котором бы компилятор сам проверял на бросание исключений и выдавал бы предупреждения, если исключения могут быть брошены. Мне кажется, что это упростило бы написание exception-safe кода. Причем не только в озвученных выше очевидных случаях (swap, move-операторы, деструкторы). Например, noexcept-блок мог бы помочь вот в такой ситуации: Здесь для корректности кода очень важно, чтобы действия, выполняемые внутри noexcept-блоков не бросали исключений. И если компилятор сможет за этим проследить, то это будет серьезное подспорье для разработчика. Но, возможно, noexcept-блок — это лишь частный случай более общей проблемы. А именно: проверки ожиданий программиста о том, что какой-то блок кода обладает определенными свойствами. Будь то отсутствие исключений, отсутствие побочных эффектов, отсутствие рекурсии, гонок данных и пр. Размышления на эту тему пару лет назад привели к идее атрибутов implies и expects. Дальше заметки в блоге эта идея не пошла, т.к. пока она лежит в стороне от моих текущих интересов и возможностей. Но вдруг она кому-то будет интересна и кого-то подтолкнет к созданию чего-то более жизнеспособного. В данной статье я попробовал рассказать о своем опыте упрощения написания exception-safe кода. Использование макросов, конечно же, не делает код красивее и компактнее. Но это работает. И коэффициент моего спокойного сна даже такие примитивные макросы повышают весьма существенно. Так что, если кто-то еще не задумывался о том, как контролировать содержимое собственных noexcept методов/функций, то может быть данная статья подтолкнет вас к размышлениям на эту тему. А если кто-то нашел способ упростить себе жизнь при написании noexcept-кода, то было бы интересно узнать, что это за способ, в чем он помогает, а в чем нет. И насколько вы сами довольны тем, что используете. Велосипедостроитель, программист-камикадзе