Romikgy, ну так я нормальный довод первый раз вижу )

тогда перечитай весь топик с сааааамого начала!   

Просмотрел  4 страницы всякого бреда с приплетением жабы, каких-то предложений о выносе из красной книге Питона, хотя 99% настольных приложений написано в VS или Delphi\Builder, вспомнил о старых добрых:
try
except,
finally,
raise
Причем в плюсах аналога finally вроде нет и ушел Дельфе радоваться.

нет. Но есть автоматические деструкторы, которые практически покрывают этот недостаток  

ээээ... это что имеется в виду? вызов деструктора при ошибке во время конструирования? 

Какое имеет отношение работа с исключениями к работе конструкторов/диструкторов классов ?

вызов деструктора при раскрутки стека.

самое прямое. Учите матчасть. При идиоме RAII автоматические деструкторы выполняют роль "чистильщиков мусора" вроде finally блоков в некоторых языках.

Это сообщение отредактировал(а) Daevaorn - 20.1.2007, 14:50

нет слов 


Resource Acquisition Is Initialization - Wikipedia, the free ...
а если в блоке try finally я не буду использовать классы вообще?

т.е. при покидании области видимости? интересно 

При "чисто ООП" программе(ну, где нет функций/переменных, а сплошные классы/объекты) - это действительно синонимы(вызов деструкторов при покидании области видимости и try ... finaly), правда, опасный блок не всегда последним идет в функции и можно ещё долго ждать, скажем, освобождения ресурса от блокировки или возврата чего-нить в первоначальное состояние. 
Когда же у нас есть и обычные переменные/функции, то автоматические деструкторы уже не помогут, скажем, разлочить файл. 
Я верно понял идею?

да. но это решается маленькой корректировкой дизайна.

не очень понимаю что такое "обычные переменные/функции". Но если рассматривать закрытие файла, то можно воспользоваться каким-либо прокси-классом, например boost::smart_handle. Поэтому и эта проблема в принципе решаема. За-то, хоть такие меры могут быть и более трудоёмки, чем просто "тупое" освобождение, но они благотворно сказываются на дизайне и вообще безопасности исключений в целом.
Конечно можно найти случай, когда ничего не поможет, но это редко и всегда решаемо какими-то другими способами.

Добавлено @ 16:23 

соболезную

вот люди иногда спрашивают, в чем смысл таких вот споров. Да вот же он - человек посмотрел википедию и открыл для себя что же такое RAII. Это же великолепно!

аналогично , только в большей степени 

имхо эту ссылку должен был дать ты , а не я!
А во вторых , можно сделать так

а можно так

и лично я в этом RAII смысла не вижу большого (лично я!)
так что знать такие тонкости , которые юзаются очень редко (при том что их можно вообще не использовать , а реализовать все по другому)
имхо это не рационально....

Возможно 

т.е. для тебя второй код лучше? Ну что же, у всех свои пристрастия

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

Это не тонкости, а правильная и полезная идиома, которой должен владеть профессионал, пишущий на С++. Она положительно влияет на безопасность исключений, дизайн классов и кода в целом. А насчет редкого использования, это не правда. На ней постоен смысл умных указателей и т.п. Используется достаточно часто.

How to catch exceptions in Visual C++

хорошо. но не переносимо, увы

это вопрос из другой оперы имхо

имхо RAII это не основной прием !!!!

она влияет , но это не панацея!
и без нее можно обойтись! так что это не основа языка
плюс

я очень давно программирую (конечно не профессионально на С++, и конечно используя и не используя исключения, от задачи зависит) и об этой не тонкости впервые услышал в этом топике, так что имхо делаю вывод что это тонкости и без них можно обойтись!