Всем привет!
Вот возникла у меня необходимость реализации такого блока (такого ключевого слова вроде как нету)
принцип действия блока: управление в finally попадает всегда, даже если были исключения.
Нужно для освобождения ресурсов
Аналогично придумал делать только с метками, но это мягко говоря некрасиво.
Что посоветуете? И интересно, а почему такая возможность не была заложена в язык?

СУВ, Kuvaldis 

возможность заложена, называется RAII. При раскрутки стека в момент исключения вываются деструкторы объектов.
PS: finally есть у MS

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

Alek86, эти умные ресурсы и представляют из себя идиому RAII .

ну если уж хочется совсем похоже на try-finally, можно попробовать так:

"всегда" в твой catch(...) не попадешь

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

maxim1000, 
код в finally выполняется всегда, и когда не было исключений и когда были, а в catch только после исключения.

Так. А что если исключения не будет ?
Суть finally в гарантированной отработке в любых условиях: было исключение, не было исключения, return отработал, управление само по себе до finally дошло...

мы должны попасть туда всегда при выходе из функции.

а... ступил 

Kuvaldis, а почему Рихтера не читаем?!...

Там же всё разъяснено в деталях

ЧАСТЬ V СТРУКТУРНАЯ ОБРАБОТКА ИСКЛЮЧЕНИЙ 

ГЛАВА 23 Обработчики завершения 
ГЛАВА 24 Фильтры и обработчики исключений


Это сообщение отредактировал(а) SergeCpp - 5.10.2007, 08:24

SergeCpp, 
SEH - это решение для конкретной среды

а может так?

и что? тоже другое поведение.

А что будет если перед вызовом 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, поправьте, если глупости говорю), вот и нужно место, где в любой ситуации можно удалить созданные объекты...

Здесь, кстати, можно поступить проще. Написать письмо в соответствующий комитет с просьбой ввести finally, а их ответ приписать здесь. (Или порыться в архиве отказных предложений  ...)

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