sev>>Ну как что будет, полетит std::bad_alloc, вестимо
sev>>Только чем это плохо?
> Например тем, что ловить ты будешь СExceptionPtr (тем более, что в
> заголовочном файле у тебя уже есть COutOfMemoryExeption).

COutOfMemoryExeption был дан скорее для примера, не нужно
рассматривать его как замену std::bad_alloc, он для этого не задумывался

> А выкинется std::bad_alloc (особенно в случае COutOfMemoryExeption), которая
> останется неперехваченной. Или я чего-то не понял?

std::bad_alloc останется неперехваченным тем кодом, который ожидал
увидеть потомка CException. Что вполне логично. Разумеется, что где-то
в программе должен быть и обработчик std::bad_alloc А также всех прочих,
порождённых от std::exception. Т.е. я не претендую на замену std::exception
своими исключениями. Мои исключения _логические_, в то время как
std::bad_alloc сугубо системное.

Как вариант, все не-CException могут ловиться через catch(...) и транслироваться
в CException-derived исключения. Ссыка на оригинальный способ это сделать
здесь уже пробегала.

>>> Проще надо ИМХО, конечно.
sev>>Предлагайте варианты...
> Ну мне такая штука была нужна, просто для записи более подробной отладочной
> информации о том, что же сбойнуло. Ну так каждое исключение на своем уровне
> просто писало в лог, то что знало и все — дальше новое throw, если нужно, и
> перехват в верху . Мне было вполне достаточно. А если речь идет о клиенте, а
> не о серваке, то юзеру вполне достаточно сказать "облом тебе", а не пугать
> кучей непонятной информации. Так что получалось дешего и сердито. Просто для
> того, чтобы что-то предлагать надо бы выснянить, я для чего конкретно такой
> огород городим.

Тут могут быть разные идеи, но я исходил из того, что _мне нужно_ иметь
список вложенных исключений a-la .NET. Я не вижу достойной альтернативы
сделать это без использования динамической памяти.

С уважением,
Евгений Суходолин
http://www.demoforge.com/