Что нового в работе с исключениями в 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) {
		std::cout << " int ctor" << std::endl;
	}

	some_exception(const some_exception & e): v(e.v) {
		std::cout << " copy ctor" << std::endl;
	}

	int v;
};

std::exception_ptr throwExceptionAndCaptureExceptionPtr() {
	std::exception_ptr currentException;
	try {
		const int throwValue = 10;
		std::cout << "throwing           " << throwValue << "..." << std::endl;
		throw some_exception(throwValue);

	} catch (...) {
		 currentException = std::current_exception();
	}

	return currentException;
}

void rethrowException(std::exception_ptr ePtr) {
	try {
		if (ePtr) {
			std::rethrow_exception(ePtr);
		}

	} catch (const some_exception & e) {
		std::cout << "catched int value: " << e.v << std::endl;
	}

	std::exception_ptr anotherExceptionPtr = ePtr;
	try {
		if (anotherExceptionPtr) {
			std::rethrow_exception(anotherExceptionPtr);
		}

	} catch (const some_exception & e) {
		std::cout << "catched int value: " << e.v << std::endl;
	}
}

void checkMakeExceptionPtr() {
	std::exception_ptr currentException = std::make_exception_ptr(some_exception(20));
	std::cout << "exception_ptr constructed" << std::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(std::promise<void> & p) {
	try {
		throw std::runtime_error("exception from thread");
	} catch (...) {
		p.set_exception(std::current_exception());
	}
}

void checkThreadAndException() {
	std::promise<void> p;
	auto result = p.get_future();

	std::thread t(worker, ref(p));
	t.detach();

	try {
		result.get();
	} catch (const std::runtime_error & e) {
		std::cout << "runtime error catched from async worker" << std::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 std::runtime_error {
public:
	our_exception(const std::string & e) : std::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) {
	std::cerr << "our exception catched: " << e.what();

	if (catchNested) {
		try {
			rethrow_if_nested(e);
		} catch (const third_party_exception & e) {
			std::cerr << ", low level reason is: " << e.code;
		}
	}

	std::cerr << std::endl;
}

void exceptionProcessing() {
	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
	std::cout << "func called, object size: " << sizeof(var) << std::endl;
}

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

	/// @note function is not actually called
	std::cout << "noexcept func<int>:         " << noexcept(func<int>()) << std::endl;
	std::cout << "noexcept func<vector<int>>: " << noexcept(func<std::vector<int>>()) << std::endl;
}

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

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

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

Резюме

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

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

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

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

Update 1. Убрал из примеров using namespace std, теперь видно какие сущности относятся к стандартной библиотеке, а какие нет.