При разработке на C++ время от времени приходится писать код, в котором исключения не должны возникать. Например, когда нам нужно написать не бросающий исключений swap для собственных типов или определить noexcept move-оператор для своего класса, или вручную реализовать нетривиальный деструктор.

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

Например, если у меня есть вот такие типы и функции:

class first_resource {...};
class second_resource {...};

void release(first_resource & r) noexcept;
void close(second_resource & r);

и есть некий класс resources_owner, который владеет объектами типа first_resource и second_resource:

class resources_owner {
   first_resource first_resource_;
   second_resource second_resource_;
   ...
};

то я могу написать деструктор resources_owner следующим образом:

resources_owner::~resources_owner() noexcept {
   // Функция release() не бросает исключений, поэтому просто вызываем ее.
   release(first_resource_);

   // А вот функция close() может бросать исключения, поэтому
   // обрамляем ее try-catch.
   try{ close(second_resource_); } catch(...) {}
}

В каком-то смысле noexcept в C++11 сделал жизнь C++ разработчика легче. Но у текущей реализации noexcept в современном C++ есть одна неприятная сторона...

Компилятор не помогает контролировать содержимое noexcept функций и методов

Допустим, что в приведенном выше примере я ошибся: почему-то посчитал, что release() помечена как noexcept, но на самом деле она таковой не является и может бросать исключения. Это означает, что когда я пишу деструктор с использованием такой бросающей release():

resources_owner::~resources_owner() noexcept {
   release(first_resource_); // Нет try-catch вокруг вызова
   ...
}

то я напрашиваюсь на неприятности. Рано или поздно эта 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 код.

Сделано это было при помощи нескольких макросов, которые были расставлены по коду в нужных местах. Например, тривиальный случай:

template< typename Message_Builder >
void
trigger_error_and_close( Message_Builder msg_builder ) noexcept
{
   // An exception from logger/msg_builder shouldn't prevent
   // a call to close().
   restinio::utils::log_error_noexcept( m_logger, std::move(msg_builder) );

   RESTINIO_ENSURE_NOEXCEPT_CALL( close() );
}

А вот менее тривиальный фрагмент:

void
reset() noexcept
{
   RESTINIO_STATIC_ASSERT_NOEXCEPT(m_context_table.empty());
   RESTINIO_STATIC_ASSERT_NOEXCEPT(
         m_context_table.pop_response_context_nonchecked());
   RESTINIO_STATIC_ASSERT_NOEXCEPT(m_context_table.front());
   RESTINIO_STATIC_ASSERT_NOEXCEPT(m_context_table.front().dequeue_group());

   RESTINIO_STATIC_ASSERT_NOEXCEPT(make_asio_compaible_error(
         asio_convertible_error_t::write_was_not_executed));

   for(; !m_context_table.empty();
      m_context_table.pop_response_context_nonchecked() )
   {
      const auto ec =
         make_asio_compaible_error(
            asio_convertible_error_t::write_was_not_executed );

      auto & current_ctx = m_context_table.front();
      while( !current_ctx.empty() )
      {
         auto wg = current_ctx.dequeue_group();

         restinio::utils::suppress_exceptions_quietly( [&] {
               wg.invoke_after_write_notificator_if_exists( ec );
            } );
      }
   }
}

Использование этих макросов несколько раз ударило по рукам, указав на места, которые я по недосмотру воспринимал как noexcept, но которые таковыми не были.

Так что описываемый далее подход, конечно же, является самодельным лисапедом с квадратными колесами, но он ездиит… В смысле работает.

Далее в статье речь пойдет уже о реализации, которая была выделена из кода RESTinio в отдельный набор макросов.

Суть подхода

Суть подхода состоит в том, чтобы передать утверждение/оператор (stmt), которое нужно проверить на noexcept, в некий макрос. Этот макрос задействует static_assert(noexcept(stmt), msg) для проверки того, что stmt действительно noexcept, после чего подставляет stmt в код.

По сути, вот такое:

ENSURE_NOEXCEPT_STATEMENT(release(some_resource));

будет заменено на что-то вроде:

static_assert(noexcept(release(some_resource)),
   "release(some_resource) is expected to be noexcept");
release(some_resource);

Почему был сделан выбор в пользу макросов?

В принципе, можно было бы обойтись без макросов и можно было писать static_assert(noexcept(...)) прямо в коде непосредственно перед проверяемыми действиями. Но у макросов есть, по меньшей мере, пара достоинства, которые склонили чашу весов в пользу использования именно макросов.

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

static_assert(noexcept(release(some_resource)),
   "release(some_resource) is expected to be noexcept");
release(some_resource);

и

ENSURE_NOEXCEPT_STATEMENT(release(some_resource));

то видно, что с макросами основное выражение, т.е. release(some_resource) можно записать только однажды. Что уменьшает вероятность "расползания" кода со временем, при его сопровождении, когда в одном месте исправление внесли, а во втором — забыли.

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

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

Основной макрос ENSURE_NOEXCEPT_STATEMENT

Основной макрос ENSURE_NOEXCEPT_STATEMENT реализуется тривиально:

#define ENSURE_NOEXCEPT_STATEMENT(stmt) \
   do { \
      static_assert(noexcept(stmt), "this statement is expected to be noexcept: " #stmt); \
      stmt; \
   } while(false)

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

class some_complex_container {
   one_container first_data_part_;
   another_container second_data_part_;
   ...
public:
   friend void swap(some_complex_container & a, some_complex_container & b) noexcept {
      using std::swap;
      // Если swap не noexcept, то будет ошибка компиляции.
      ENSURE_NOEXCEPT_STATEMENT(swap(a.first_data_part_, b.first_data_part_));
      ENSURE_NOEXCEPT_STATEMENT(swap(a.second_data_part_, b.second_data_part_));
      ...
   }
   ...
   void clean() noexcept {
      // Если clean() не noexcept, то будет ошибка компиляции.
      ENSURE_NOEXCEPT_STATEMENT(first_data_part_.clean());
      ENSURE_NOEXCEPT_STATEMENT(second_data_part_.clean());
      ...
   }
   ...
};

В дополнение есть еще и макрос ENSURE_NOT_NOEXCEPT_STATEMENT. Он применяется для того, чтобы убедиться, что требуется дополнительный блок try-catch вокруг вызова, чтобы возможные исключения не улетели наружу:

class some_resource_owner {
   some_resource resource_;
   ...
public:
   ~some_resource_owner() noexcept {
      try {
         // Если release вдруг окажется noexcept, то try-catch не нужны и мы
         // узнаем об этом во время компиляции.
         ENSURE_NOT_NOEXCEPT_STATEMENT(release(resource_));
      } catch(...) {}
      ...
   }
   ...
};

Вспомогательные макросы STATIC_ASSERT_NOEXCEPT и STATIC_ASSERT_NOT_NOEXCEPT

К сожалению, макросы ENSURE_NOEXCEPT_STATEMENT и ENSURE_NOT_NOEXCEPT_STATEMENT могут применяться только для утверждений/операторов (statements), но не для возвращающих значение выражений (expressions). Т.е. нельзя посредством ENSURE_NOEXCEPT_STATEMENT написать так:

auto resource = ENSURE_NOEXCEPT_STATEMENT(acquire_resource(params));

Поэтому ENSURE_NOEXCEPT_STATEMENT не получается использовать, например, в циклах, где часто приходится писать что-то вроде:

for(auto i = something.get_first(); i != some_other_object; i = i.get_next()) {...}

и требуется убедиться, что вызовы get_first(), get_next(), а также операции присваивания новых значений для i не бросают исключений.

Для борьбы с такими ситуациями были написаны макросы STATIC_ASSERT_NOEXCEPT и STATIC_ASSERT_NOT_NOEXCEPT, за которыми спрятаны только static_assert-ы и ничего больше. С помощью этих макросов можно достичь нужного мне результата каким-то таким образом (компилябильность именно этого фрагмента не проверялась):

STATIC_ASSERT_NOEXCEPT(something.get_first());
STATIC_ASSERT_NOEXCEPT(something.get_first().get_next());
STATIC_ASSERT_NOEXCEPT(std::declval<decltype(something.get_first())>() =
   something.get_first().get_next());
for(auto i = something.get_first(); i != some_other_object; i = i.get_next()) {...}

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

Библиотека noexcept-ctcheck

Когда я поделился этим опытом у себя в блоге и в Facebook-е, то поступило предложение оформить описанные выше наработки в виде отдельной библиотеки. Что и было сделано: на github-е теперь лежит малюсенькая header-only библиотека noexcept-compile-time-check (или noexcept-ctcheck, если экономить на буквах). Так что все вышеописанное можно взять и попробовать. Правда там названия макросов чуть подлинее, чем использовано в статье. Т.е. NOEXCEPT_CTCHECK_ENSURE_NOEXCEPT_STATEMENT вместо ENSURE_NOEXCEPT_STATEMENT.

Что в noexcept-ctcheck не попало (пока?)

Есть желание сделать макрос ENSURE_NOEXCEPT_EXPRESSION, который можно было бы использовать вот так:

auto resource = ENSURE_NOEXCEPT_EXPRESSION(acquire_resource(params));

В первом приближении он мог бы выглядеть как-то так:

#define ENSURE_NOEXCEPT_EXPRESSION(expr) \
  ([&]() noexcept -> decltype(auto) { \
     static_assert(noexcept(expr), #expr " is expected to be noexcept"); \
     return expr; \
  }())

Но есть смутные подозрения, что здесь есть некие подводные камни, о которых я еще не задумывался. В общем, до ENSURE_NOEXCEPT_EXPRESSION руки пока не дошли :(

А если помечтать?

Моя давняя мечта — это заиметь в C++ noexcept-блок, в котором бы компилятор сам проверял на бросание исключений и выдавал бы предупреждения, если исключения могут быть брошены. Мне кажется, что это упростило бы написание exception-safe кода. Причем не только в озвученных выше очевидных случаях (swap, move-операторы, деструкторы). Например, noexcept-блок мог бы помочь вот в такой ситуации:

void modify_some_complex_data() {
   // Выполняем предварительные действия.
   one_container_.modify();
   // Отмечаем, что состояние изменилось. Важно, что здесь мы не ждем исключений.
   // В противном случае следовало делать это внутри блока try.
   noexcept { current_age_.increment(); }
   // Если далее возникают исключения, то нужно отменить уже сделанные изменения.
   try {
      another_container_.modify();
      ...
   }
   catch(...) {
      noexcept { // Делаем действия, которые не должны бросать исключений.
         current_age_.decrement();
         one_container_.rollback_modifications();
      }
      throw;
   }
}

Здесь для корректности кода очень важно, чтобы действия, выполняемые внутри noexcept-блоков не бросали исключений. И если компилятор сможет за этим проследить, то это будет серьезное подспорье для разработчика.

Но, возможно, noexcept-блок — это лишь частный случай более общей проблемы. А именно: проверки ожиданий программиста о том, что какой-то блок кода обладает определенными свойствами. Будь то отсутствие исключений, отсутствие побочных эффектов, отсутствие рекурсии, гонок данных и пр.

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

Заключение

В данной статье я попробовал рассказать о своем опыте упрощения написания exception-safe кода. Использование макросов, конечно же, не делает код красивее и компактнее. Но это работает. И коэффициент моего спокойного сна даже такие примитивные макросы повышают весьма существенно. Так что, если кто-то еще не задумывался о том, как контролировать содержимое собственных noexcept методов/функций, то может быть данная статья подтолкнет вас к размышлениям на эту тему.

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