Собственно, сабж. По текущей архитектуре кода исключение должно броситься в конструкторе объекта, если инициализация прошла неуспешно. Код ошибки вернуть не могу - конструктор всё-таки .

А что вы делаете в таких случаях?

JackYF, замечательный опрос!

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

Это сообщение отредактировал(а) marcusmae - 9.1.2008, 19:37

Ответил 1-й вариант(надо бросить - бросаю), но есть у меня маленькое уточнение .
"Надо" - понятие растяжимое. Скажем так, если можно без крови перепроектировать несколько классов, чтобы бросать исключение не пришлось, то я именно так и сделаю. Другими словами - не всегда "надо", даже если кажется, что "просто необходимо" .

ИМХО если пользуешься исключениями, так пользуйся, а как раз в конструкторе удобно, не надо ничего изобретать.

Я выбрала первый вариант... Строго говоря, что в конструкторе исключения бросать, что в других функция - лишь бы не в деструкторе.
Однако на практике я делаю все же немного по-другому, особенно если речь идет о глобально используемых классах-объектах. Такой конструктор (который может привести к исключению) я делаю приватным и заворачиваю в фабричную функцию (обычно статик этого же класса). И она возвращает уже указатель или 0, обрабатывая исключения или просто проверяя условия внутри себя. 
Решение зависит от контекста - ведь исключения исключениям рознь. Неправильный параметр - если только его не пользователь ввел (или он откуда-то извне появился) - это должно быть выковырено на этапе отладки - здесь лучше исключения и\или ASSERT's.
А вот несуществующий файл или отсутствие ресурса или еще что-то в этом роде - другое дело. При этом, если обработка неудачного создания всегда одинакова, фабричная функция имеет преимущества - пишешь обработку один раз, а потом только if 0 return - несколько короче, чем try\catch, да еще если неоднократно...

Разве? ЕМНИП, контейнеры STL по этому поводу не гарантируют уже не помню что, если в конструкторе может выброситься исключение.
Скажем, если я создаю вектор из 10 элементов, и 5-й конструктор выбросил исключение - то в каком состоянии останется контейнер?

Его конструктор выкинет исключение(как new T[]).

отлично, а кто будет освобождать память из-под 4 элементов, конструкторы которых уже вызвались?

Ну, во-первых, память выделяется под всё сразу. А, во-вторых, как и в случае new T[], вызовутся деструкторы уже сконструированных элементов в порядке, обратном конструированию, потом освободится память(та что под всё сразу) и, наконец, исключение будет переброшено.

Выводgcc версия 4.1.2 (Gentoo 4.1.2)
Я что-то делаю нетак?

в том-то и дело, что могут не вызваться - конструктор не отработал - мы не имеем право вызывать деструктор.

Добавлено через 57 секунд
о, bsa, отлично, уже живой пример есть 

Угу. Замени if (--counter) на if (!--counter).

Добавлено через 1 минуту и 12 секунд

Так, давай, с чувством, с толком, с расстановкой - чей конструктор не отработал, чей деструктор не имеем право вызвать и т.д. .

Вот Standard-Library Exception Safety от Страуструпа [pdf, 200kB] как дополнение к его же FAQу

  
Там не только это нужно было исправить.Зато вывод стал таким:

итак, пример.
пускай есть класс с двумя динамическими полями. Пускай в конструкторе под них выделяется память. Что будет, если я выброшу исключение после того, как память под первое поле уже выделил, а под второе ещё нет?
1) деструктор вызовется. При попытке освободить память из-под второго поля (там мусор, так как конструктор ничего не успел с ним сделать) - сегфолт.
2) деструктор не вызовется. Память, выделенная под первое поле, останется витать в воздухе.

Ещё варианты?