А что будет если перед вызовом throw; исключений небыло. Ведь throw без параметров просто повторно запускает последнее перехваченное исключение. 

Это сообщение отредактировал(а) Lazin - 5.10.2007, 09:40

А что если попробовать так.

Конечно, дублирование кода = плохо, поэтому можно поступить следующим образом:
Кидать исключение, если все прошло успешно, и обрабатывать во вложенном try..catch:



Это сообщение отредактировал(а) antropod - 5.10.2007, 13:52

antropod, а не легче RAII использовать и не париться? ;) ты бы ещё longjump использовал  

Будет медленнее работать, исключения не расчитаны на то, чтобы их всё время кидали  

Разве SEH отматывает стек? 

я про то, что SEH - это платформо-зависимая вещь

симуляция блока try - finally с помощью #define

http://rsdn.ru/article/cpp/try_finally.xml

ограничение на использование запятых там плохое ((
нельзя функции многие вызвать

Ещё и такая конструкция(достаточно распространённая, между прочим) облажается(должна вывести "catch finally"):

с этим дефайном?





так же нельзя, два catch(...)

О чём я и сказал:

гы

а как она может быть тогда растпространенной, если она не компилируется? )

Эта конструкция распространена в языках, поддерживающих finally - там она компилируется и работает.
В С++ finally нет, а этот пример я привёл в подтверждение того, что упомянутое здесь решение через define далеко не самое лучшее(с RAII вообще ничего не сравнится ).

  Я обзадумался, обратился к многоуважаемому талмуду достопочтенного мистера Стенли Б.Липпмана...

На мой взгляд, все дело в том, что хронологически C++ механизм exception появился раньше введения finally в других языках и Microsoft реализации (а);

нацеленность на гибкость (б)
С самого начала заложено, что после обработки исключения программа не должна автоматически вызывать terminate, а должна иметь возможность продолжить работу со следующей инструкции за блоком try-catch. Конструкция finally в том виде, в котором она применяется, чаще всего принуждается к уничтожению динамических объектов, освобождению ресурсов (и т.д. по списку), и в этом случае в 99% случаев уже нет смысла говорить о дальнейшем выполнении программы ( или функции). 

хмм... если уж поразмышлять о причинах отсутствия finally в С++, то мне кажется, что дело, скорее, в наличии там стековых переменных, которые автоматически удаляются с вызовами соответствующих деструкторов при при выходе из блока по return, throw или goto
в Delphi с этим сложнее: более-менее сложных стековых объектов просто нет, а те, что в куче, сами по себе не удаляются (знатоки Delphi, поправьте, если глупости говорю), вот и нужно место, где в любой ситуации можно удалить созданные объекты...