Что нового в работе с исключениями в C++11

В интернете довольно много говорят о новых возможностях C++11: auto, lambda, variadic templates. Но как-то обошли стороной новые возможности работы с исключениями, которые предоставляет язык и стандартная библиотека.

От предыдущей версии стандарта остался механизм генерации исключений (throw), проверка того, что мы находимся в процессе обработки исключения (std::uncaught_exception), механизм остановки, если исключение не было обработано. Также есть иерархия стандартных исключений на базе класса std::exception.

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

exception_ptr

Итак, самое первое, с чем мы можем столкнуться — это std::exception_ptr. Этот тип позволяет в себе хранить исключение абсолютно любого типа. Стандарт не оговаривает каким образом получен этот тип. Это может быть typedef, это может быть реализация класса. Его поведение сходно поведению std::shared_ptr, то есть его можно копировать, передавать в качестве параметра, при этом само исключение не копируется. Основное предназначение exception_ptr — это передача исключений в качестве параметров функции, возможна передача исключений между потоками. Таким образом, объекты данного типа позволяют сделать обработку ошибок более гибкой:

struct some_exception { 	explicit some_exception(int x): v(x) { 		cout << " int ctor" << endl; 	}  	some_exception(const some_exception & e): v(e.v) { 		cout << " copy ctor" << endl; 	}  	int v; };  exception_ptr throwExceptionAndCaptureExceptionPtr() { 	exception_ptr currentException; 	try { 		const int throwValue = 10; 		cout << "throwing           " << throwValue << "..." << endl; 		throw some_exception(throwValue);  	} catch (...) { 		 currentException = current_exception(); 	}  	return currentException; }  void rethrowException(exception_ptr ePtr) { 	try { 		if (ePtr) { 			rethrow_exception(ePtr); 		}  	} catch (const some_exception & e) { 		cout << "catched int value: " << e.v << endl; 	}  	exception_ptr anotherExceptionPtr = ePtr; 	try { 		if (anotherExceptionPtr) { 			rethrow_exception(anotherExceptionPtr); 		}  	} catch (const some_exception & e) { 		cout << "catched int value: " << e.v << endl; 	} }  void checkMakeExceptionPtr() { 	exception_ptr currentException = make_exception_ptr(some_exception(20)); 	cout << "exception_ptr constructed" << endl;  	rethrowException(currentException); }  void exceptionPtrSample() { 	rethrowException(throwExceptionAndCaptureExceptionPtr()); 	checkMakeExceptionPtr(); } 

Если мы запустим функцию exceptionPtrSample на выполнение, то увидим примерно следующий результат:

throwing 10…
int ctor
catched int value: 10
catched int value: 10
int ctor
copy ctor
copy ctor
exception_ptr constructed
catched int value: 20
catched int value: 20

Для того чтобы можно было удобно работать с exception_ptr, есть несколько вспомогательных функций:

• current_exception — данная функция возвращает exception_ptr. Если мы находимся внутри блока catch, то возвращает exception_ptr, который содержит обрабатываемое в данный момент текущим потоком исключение, если вызывать ее вне блока catch, то она вернет пустой объект exception_ptr
• rethrow_exception — данная функция бросает исключение, которое содержится в exception_ptr. Если входной параметр не содержит исключения (пустой объект), то результат не определен. При этом msvc кидает std::bad_exception, а программа собранная с помощью gcc-4.7.2 неожиданно завершается.
• make_exception_ptr — данная функция, может сконструировать exception_ptr без бросания исключения. Ее предназначение аналогично функции std::make_shared — конструирование объекта. Ее выполнение аналогично функции throwExceptionAndCaptureExceptionPtr. В реализации от gcc-4.7.2 make_exception_ptr делает два копирования объекта some_exception.

Передача исключений между потоками

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

void worker(promise<void> & p) { 	try { 		throw runtime_error("exception from thread"); 	} catch (...) { 		p.set_exception(current_exception()); 	} }  void checkThreadAndException() { 	promise<void> p; 	auto result = p.get_future();  	thread t(worker, ref(p)); 	t.detach();  	try { 		result.get(); 	} catch (const runtime_error & e) { 		cout << "runtime error catched from async worker" << endl; 	} }

Вообще, многопоточность в C++11 — это обширная тема, там есть свои тонкости, ньюансы и о них следует писать отдельно. Сейчас мы рассмотрим этот пример только ради передачи исключения. Запускаем функцию worker в отдельном потоке, и эта функция кидает исключение. Объект класса promise позволяет организовать связь между разными потоками, и атомарно передать значения из одного потока в другой (или исключение). В данном примере мы как раз пользуемся методом set_exception, который принимает exception_ptr в качестве параметра. Для того чтобы получить значение, мы создаем объект класса future — это наш result и вызываем метод get. Также необходимо у потока вызвать метод detach или join, так как при разрушении объекта t в деструкторе проверяется, чтобы joinable() == false, иначе вызывается std::terminate. Скорее всего, это связано с тем, чтобы программист не «отпускал потоки на волю», а всегда следил за ними (либо отпускал явно с помощью метода detach)

Отдельно стоит сказать об использовании многопоточности в gcc-4.7. Изначально этот пример у меня не работал (выбрасывал исключение), погуглив, я выяснил, что для использования std::thread необходимо передать линкеру флаг -pthread. Так как я использую CMake в качестве системы сборки, то эта задача упрощается (тут сложность может возникнуть при использовании gcc на разных платформах, например на sparc solaris используется флаг -thread вместо -pthread) — есть специальный CMake модуль Threads, в котором эта проблема решена:

find_package(Threads REQUIRED)
#…
target_link_libraries(cxx_exceptions ${CMAKE_THREAD_LIBS_INIT})

Nested exceptions

Как видно из названия, данный механизм позволяет «прицепить» к кидаемому исключению другие исключения (которые могли быть брошены раньше). Например, если у нас есть своя иерархия исключений, то мы можем ловить все «сторонние» исключения, прицеплять их к своим исключениям, а при обработке своих исключений мы можем выводить доп. информацию, которая к ним «прицеплена» (например, при отладке, мы можем печатать информацию о сторонних исключениях). Хороший пример использования nested exception приведен на cppreference.com, мой пример, отчасти пересекается с ним:

struct third_party_exception { 	explicit third_party_exception(int e) : code(e) { 	}  	int code; };   void third_party_worker() { 	throw third_party_exception(100); }  class our_exception : public runtime_error { public: 	our_exception(const string & e) : runtime_error("our error: " + e) { 	} };  void ourWorker() { 	try { 		third_party_worker(); 	} catch (...) { 		throw_with_nested(our_exception("worker failed")); 	} }  void exceptionHandler(const our_exception & e, bool catchNested) { 	cerr << "our exception catched: " << e.what();  	if (catchNested) { 		try { 			rethrow_if_nested(e); 		} catch (const third_party_exception & e) { 			cerr << ", low level reason is: " << e.code; 		} 	}  	cerr << endl; }  void nestedExceptionSample() { 	try { 		ourWorker(); 	} catch (const our_exception & e) { 		exceptionHandler(e, false); 	}  	try { 		ourWorker(); 	} catch (const our_exception & e) { 		exceptionHandler(e, true); 	} }

Итак, у нас есть сторонняя функция, которая кидает исключение, мы можем написать адаптер, который ловит «сторонние» исключения, и из них делает «наше» исключение: в качестве «сторонней» функции и «нашей» функции выступают соответственно third_party_worker и ourWorker. Мы ловим все исключения, и бросаем далее уже наше (our_exception) исключение, при этом, к нему было прицеплено какое-то (мы в принципе можем и не знать какое) «стороннее» исключение. После этого работаем уже с нашими исключениями. При этом, если нам понадобится более детальная информация о том, что происходило на «нижнем» уровне, то мы всегда можем вызвать функцию rethrow_if_nested. Данная функция анализирует, если ли прицепленное (вложенное) исключение, и если есть, то бросает это вложенное исключение. Функция exceptionHandler принимает «наше» исключение и дополнительный флаг, который разрешает или запрещает вывод информации о стороннем исключении. Мы можем управлять выводом сторонних исключений, управляя параметром catchNested, например, из файла конфигурации (или в зависимости от сборки — Release, Debug).

Для работы с nested exception есть один класс и две функции:

• nested_exception — данный класс «подмешивается» к бросаемому объекту при вызове функции std::throw_with_nested — этот класс также позволяет вернуть вложенное исключение (exception_ptr) с помощью метода nested_ptr. Также этот класс имеет метод rethrow_nested, который бросает вложенное исключение
• throw_with_nested — данная шаблонная функция принимает объект некоторого типа (назовем его InputType), и бросает объект который является наследником std::nested_exception и нашего InputType (в реализации от gcc — это шаблонный тип, который наследуется от nested_exception и InputType). Таким образом, мы можем ловить как объект нашего типа, так и объект типа nested_exception и уже потом получать наш тип через метод nested_ptr
• rethrow_if_nested — данная функция определяет, есть ли у объекта вложенное исключение, и если есть, то бросает его. Реализация может использовать dynamic_cast для определения наследования

В принципе, механизм nested exception довольно интересный, хотя реализация может быть довольно тривиальна, ее можно сделать самому, с помощью ранее описанных функций current_exception и rethrow_exception. В той же реализации gcc, класс nested_exception содержит одно поле типа exception_ptr, которое инициализируется в конструкторе с помощью функции current_exception, а реализация метода rethrow_nested просто вызывает функцию rethrow_exception.

Спецификация noexcept

Данный механизм можно рассматривать как расширенный (и ныне устаревший) механизм throw(). Основное его предназначение как и раньше — гарантия того что, функция не бросит исключение (если гарантия нарушается, то вызывается std::terminate).

Используется этот механизм в двух видах, аналогично старому throw()

void func() noexcept { //... }

И в новом виде:

void func() noexcept(boolean_expression_known_at_compile_time) { //... }

При этом, если значение выражения вычислено как истина, то функция помечается как noexcept, иначе, такой гарантии нет.
Также есть соответствующий оператор noexcept(expression), который тоже выполняется в compile time, этот оператор возвращает истину, если выражение не бросает исключение:

void noexceptSample() { 	cout << "noexcept int():         " << noexcept(int()) << endl; 	cout << "noexcept vector<int>(): " << noexcept(vector<int>()) << endl; } 

Данный код для gcc-4.7.2 выводит:

noexcept int(): 1
noexcept vector<int>(): 0

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

template <typename InputTypeT> void func() noexcept(noexcept(InputTypeT())) { 	InputTypeT var; 	/// do smth with var 	cout << "func called, object size: " << sizeof(var) << endl; }  void noexceptSample() { 	cout << "noexcept int():         " << noexcept(int()) << endl; 	cout << "noexcept vector<int>(): " << noexcept(vector<int>()) << endl << endl;  	/// @note function is not actually called 	cout << "noexcept func<int>:         " << noexcept(func<int>()) << endl; 	cout << "noexcept func<vector<int>>: " << noexcept(func<vector<int>>()) << endl; }

Данный пример выводит:

noexcept int(): 1
noexcept vector<int>(): 0

noexcept func<int>: 1
noexcept func<vector<int>>: 1

Резюме

Стандарт C++11 привнес много нового в обработку ошибок, конечно, ключевой особенностью здесь остается exception_ptr и возможность передачи произвольных исключений как обычные объекты (в функции, передавать исключения между потоками). Раньше, в каждом потоке приходилось писать развесистый try… catch для всех исключений, а этот функционал существенно минимизирует количество try… catch кода.

Также появилась возможность создавать вложенные исключения, в принципе в библиотеке boost есть механизм boost::exception, который позволяет прикреплять к объекту произвольные данные (например коды ошибок, свои сообщения и пр), но он решает другие задачи — передачу произвольных данных внутри исключения.

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

Как обычно, все примеры выложены на github