RAII и необрабатываемые исключения

If no matching handler is found, the function std::terminate() is called; whether or not the stack is
unwound before this call to std::terminate() is implementation-defined (15.5.1).

Вот это поворот. Спасибо. Неожиданно. У меня шок

какой какашный код у конструктора класса LockNet. Что будет если new Network бросит исключение?

Единственная проблема, которую я вижу в модели RAII — это исключения в деструкторах.

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

Другая проблема — освобождение блокировок. Допустим, есть класс MutexLock, конструктор которого захватывает mutex, а деструктор — освобождает. Все вроде бы хорошо, но если мутекс был освобожден в результате исключения, возникшего при работе с защищаемой структурой — ее состояние при освобождении мутекса может оказаться испорченным. Нужно либо принимать меры к откату всех изменений, либо иметь какой-то флаг «consistency», который будет проверяться при последующем доступе к этой структуре.

Это, ваш пример не демонстрирует проблему с деструкторами.
Логично, что если main() не ловит исключение, оно перехватывается в std::terminate()
Важно понимать, что из std::terminate поток уже не возвращается. Поэтому логично, что до деструкторов дело не доходит.

Вместо того, чтобы давить исключение в testShared(), можно обернуть весь main()
Как-то так:

int main()
{
	try
	{
		vector<shared_ptr<Slot>> vec {make_shared<Slot>("0"), make_shared<Slot>("1"), make_shared<Slot>("2"), make_shared<Slot>("3"), make_shared<Slot>("4")};

		for (auto& x:vec)
				testShared(x);
	}
	catch(const std::exception& e)
	{
		std::cerr<<e.what()<<std::endl;
	}
	catch(...)
	{
		std::cerr<<"Unknown exception"<<std::endl;
	}

    return 0;
}

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

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

Например, пусть у нас есть транзакция, мы её оборачиваем RAII. Если коммит не проиходит, то происходит автоматический rollback() в деструкторе.

#include <iostream>
#include <vector>
#include <memory>
#include <string>
#include <exception>

class Transaction
{
	bool active;
public:
	Transaction() : active(false)
	{
		std::cout<<"begin transaction"<<std::endl;
		active=true;
	}

	~Transaction()
	{
		rollback();
	}

	void commit()
	{
		if(!active)
			return;
		std::cout<<"commit transaction"<<std::endl;
		active=false;
	}

	void rollback()
	{
		if(!active)
			return;

		std::cout<<"rollback transaction"<<std::endl;
		active=false;
	}
};

void do_something()
{
}

int main()
{
	try
	{
		Transaction tr;
		do_something();
		tr.commit();
	}
	catch(const std::exception& e)
	{
		std::cerr<<e.what()<<std::endl;
	}
	catch(...)
	{
		std::cerr<<"Unknown exception"<<std::endl;
	}

    return 0;
}

Вывод ожидаемый:

begin transaction
commit transaction

Теперь допустим в процессе обработки данных что-то пошло не так:

void do_something()
{
	throw std::runtime_error("processing data failed");
}

Транзакция нормально откатывается:

begin transaction
rollback transaction
processing data failed

Теперь допустим, что в процессе обработки данных исключение не генерируется, но commit() не происходит, скажем по логическим причинам в самой проге. Тогда автоматом вызовется rollback() из деструктора. И вот допустим уже в rollback() происходит исключение:

	void Transaction::rollback()
	{
		if(!active)
			return;
		throw std::runtime_error("something bad happens when we rollback transaction");

		std::cout<<"rollback transaction"<<std::endl;
		active=false;
	}

bool do_something()
{
	return false;
}

int main()
{
...
		Transaction tr;
		if(!do_something())
			return 1;
		tr.commit();
...
}

О боже! Мы не словили исключение в деструкторе и ничего не произошло. Мы успешно добрались до catch():

begin transaction
something bad happens when we rollback transaction

И вот только, если исключение в деструкторе генерируется в процессе обработки другого исключение, тогда у нас проблемы:

	void Transaction::rollback()
	{
		if(!active)
			return;
		throw std::runtime_error("something bad happens when we rollback transaction");

		std::cout<<"rollback transaction"<<std::endl;
		active=false;
	}

void do_something()
{
	throw std::runtime_error("processing data failed");
}

int main()
{
...
		Transaction tr;
		do_something();
		tr.commit();
...
}

Это весь вывод:

begin transaction

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

Можно сделать так:

	~Transaction()
	{
		try
		{
			rollback();
		}
		catch(...)
		{
			if(!std::uncaught_exception())
				throw;
		}
	}

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

А что делать системам где нету исключений?

Джон Калб говорил об этом на CppCon 2014 (ну и не только там): Exception-Safe Code, см. слайд 95. А так да, годное замечание, с ходу это неочевидно.