Есть у меня преподаватель, с легкой руки которого мы здесь на нескольких листах рассуждали о строках в С++
НА очереди исключения...
Ссылаясь на интервью Хейлсберга - автора С#(правда, я их не нашел), были даны принципы использования исключений, не нарушающих принципы структурного программирования:
1. Все исключения должны иметь общий базовый класс

2. Объекты исключений должны располагаться в динам. памяти. Это камень в сторону С++. Таким образом мы не можем сказать, откуда в общем случае пришло исключение. + многократное копирование по стеку при раскрутке (есть в Страуструпе)

3. В объекте должна быть ссылка на предыдущее исключение в контексте которого возникла данная (так сделано в .NET только c Frammework 2.0 )

4. Использование исключений для управления ходом работы проги зарещено. (у Страуструпа есть и намеки на такое нецелевое использование)

5. Касается того, что все таки объекты должны быть только динамические -> слова по поводу try... finally (уже обсуждали)

6. Обработка исключений с поглощением допустима лишь на самом верхнем уровне (сюда цикл обработки сообщений и т.д)

Скажу так: препод этот очень грамотный, работает как раз на С++, в Check Point (который делает Zone Alarm и т.д.) Т.е. в компетентности его сомневаться не приходится. Но сам он дельфист.

В общем, хотелось бы услышать ваше мнение, дорогие форумчане 

СУВ, Kuvaldis

Это сообщение отредактировал(а) Kuvaldis - 11.1.2008, 11:22

Ыыыы, стрелять этих Дельфистов надо... 
Ну давай поговорим .


Угу... Должны... std::exception для того и сделан(а также несколько классов std::logic_error, std::domain_error и т.д.)...
И тем не менее, страна свободная, свобода слова и т.п. - никто не мешает тебе бросить int или char * или объект пользовательского типа, не являющегося наследником std::exception.



1. Зачем? Ну будут они в "динамической памяти"(она что, чем-то отличается? 0_о) - что изменится?
2. Многократных копирований реализации имеют право избегать и, поверь, они именно так и поступают.
3. Копирования не избежать, если написано catch(MyException e){ ... }, но что мешает написать catch(const MyException &e){ ... }(опять же свобода программерского слова - хочет копирований пишет так, не хочет - пишет "нормально")?



А можно пример для тупых и, желательно на пальцах что это такое и зачем это нужно, потому что я могу бросить исключение просто так(потому что мне не понравился нулевой указатель, к примеру) - куда будет ссылаться такая "ссылка на предыдущее исключение"?


Согласен... И тем не менее, в .NET'е они используются для того, чтобы прервать поток, к примеру .
Утверждение в общем случае хорошее, но, оно применимо к любому языку, ибо ни один язык не может запретить пользоваться тебе исключениями вместо if'а.



finally? С++ имеет семантику автоматический объектов и, посему finally ему не нужен по определению(RAII).


Крайне неверное утверждение. Ошибка должна обрабатываться в том месте, которое умеет эту ошибку обрабатывать(читай в том месте, которое знает что с ней делать), не раньше и не позже. Примеры приводить нужно?



В его авторитете я не сомневаюсь, также, как и не сомневаюсь в том, что отсутствие в языке семантики автоматических объектов(как класса вообще), отсутствие понятия константности объекта, отсутствие статических инструментов(всё в run-time), а также, наличие сборщика мусора(относится к джава-дотнетам) проедает мозг, накладывает отпечаток и т.д., так что в компетентности Дельфистов относительно устройства языка С++(а точнее того, что они хотели бы сделать из С++) я сомневаюсь .

archimed7592, 
Честно говоря, я это и хотел в интервью найти, но не нашел. :( Не знаю, просветить не успели, так как пара закончилась 
Но эту фичу можно и не юзать (ссылка 0 )

имелось в виду throw;   // повторная генерация

Нда, это в целом очень напоминает .NET-овые исключения : базовый класс Exception, исключения хранят ссылки на дерево вложенных исключений, приведших к данному, хранят трассу вызовов, в связи с чем не очень понятно утверждение о том, что



помимо это специализируются (например, ArgumentException в числе прочего указывает на имя аргумента).

С одной стороны, подход грамотный при разработке больших и/или устойчивых, защищённых программ. Надстройка над C#, SpeC# форсирует проработку исключений введением контрактов на вызовы, например :


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


Хм, а по-моему, практикуется. Допустим, если какой-то catch-блок несумел обработать исключение, то он пробрасывает его вверх более общим обработчикам, а если сумел, то "проглотил" ошибку, и программа поехала себе дальше. Чем не управление?

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


Ха-ха  Хорошие доводы, archimed7592.
Не считаю свой мозг совсем уж проеденым, все больше и больше отхожу от .NET к плюсам, и чувствую себя в них намного комфортнее 

Это сообщение отредактировал(а) marcusmae - 28.10.2007, 23:48

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

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


Гхм... Опять я тебя не понимаю: давай на пальцах, что подразумевалось под исходным утверждением и при чём здесь rethrow?


А можно конструктивно: что понимается под слабой поддержкой исключений и чем С++ в этом плане слабже .net'а?


Ну, скажем, в том же .net "мощная система исключений" позволяет полностью узнать контекст, IIRC, только в отладочном режиме.
Опять же, что понимается под "должна помочь разработчикам сего глюкалова понять из-за чего это происходит, т-есть получить информацию о контексте выполнения программы в этот момент." - на пальцах(на примерах).

я ни в коем случае не сторонник .NET
но мне кажется управляемый код априорно более гибок (но не быстр естественно) во всех отношениях (и в плане исключений в частности)
динамическое формирование кода, перекомпиляция в run-time и все такое

Типа, отмазался .


В априоре гибком коде возможно RAII? Или может быть там возможны такие же мощные(читай compile-time) шаблоны?
Список можно продолжить .


Рефлексия? Да ну её... Ну вот ты хоть раз динамически чего-нибудь формировал? 


Речь про JIT? А в чём плюсы этого подхода(кроме мифической кроссплатформенности)?

Да ладно чуваки... Расслабтесь посмотрите какой - нибудь фильм... А потом на свежую голову сядете за комп

нет, не только в кроссплатформенности
допустим есть некоторый код, который постоянно выполняется (какой-нибудь сервер)
виртуальная машина (CLR, JRE) в зависимости от внешних факторов (например какая-либо ветвь кода выполняется только в 5% всех случаев) может перекомпилировать (=оптимизировать) код с их учетом

ну согласись, это тоже не аргумент
я лично вообще особо с .NET/Java не работал, с Reflection тем более
но это же не означает, что она бесполезна

опять таки, в С++ compile-time шаблоны, в .NET run-time
и что?
это ортогональные понятия
с другой стороны, модифицировав компилятор какого-либо языка .NET, можно получить те же мощные compile-time шаблоны
а вот обратное не верно (т. е какую-либо фишку .NET легко портировать в С++)
что я так .NET защищаю     

Добавлено через 4 минуты и 8 секунд

кроссплатформенность то настоящая
тут просто много других причин (это про .NET)
ну а Java реально кроссплатформенна

Опять же - мифическая возможность .
Реальные JIT'ы так делают? Сомневаюсь.



Ну почти бесполезна .
Она помогает, дизайнеру, к примеру, узнать какие есть свойства у компонента(пользовательского).
Мы где-то на исходниках холиварили на тему применимости рефлексии - ничего убедительного в пользу рефлексии сказанно не было.



Опять таки: ты знаком с тем, как реализуются run-time шаблоны в .net? 
По идее, то же самое можно сделать в С++ с помощью интерфейсов и обыновенных(нешаблонных) классов .

Добавлено через 2 минуты и 35 секунд
griker, ты по моему перепутал тематику с флеймом.



Хорошо, С++ тоже кроссплатформеный . Только перекомпилировать нужно самому .

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

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

Добавлено через 2 минуты и 10 секунд

  я не спорю
только типы кроссплатформенности разные

Это сообщение отредактировал(а) MAKCim - 29.10.2007, 10:51

Я бы хотел напомнить что тема называется: Поговорим про исключения

Видел когданибудь в ХР окошко с сообщением: "Программа выполнила недопустимую инструкцию и будет закрыта, бла-бла-бла..." - так-вот это поведение по умолчанию при возникновении необработанного исключения, и его можно переопределить. Например можно предложить пользователю послать отчет об ошибке разработчикам. 

Да что там - Макс главный флудогон этого раздела .



Видел. К чему всё это? К тому что бывают исключения про которые "забыли"? И то, что в этом случае помогут ссылки на "предыдущие" исключения? Хорошо, допустим... Осталось понять как они помогут и по какому принципу они предыдущие и следующие?

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

Это сообщение отредактировал(а) MAKCim - 29.10.2007, 11:43

  Ребят, а вот насчет вложенных исключений. В можно ли в С++ защищенные секции вкладывать друг в друга? Чтобы отрабатывать корректно  исключения. 
  Например в делфях я могу написать так

А что произойдет, например, при обращении к уже удаленному объекту, из-за какой-нибудь ошибки. Даже если ты знаешь как это событие перехватить, то как потом его обрабатывать? Единственный вменяемый способ - не обрабатывать такое исключение, а пропустить его, чтоб оно дошло до самого до main-a   .

Вложенные исключения нужны для того что-бы определить первоначальный источник исключения, наверное:

разница в том, что исключение сохраняет информацию о всех обработчиках, в которых оно было перехвачено
вам оно надо, мне лично нет 


Это сообщение отредактировал(а) Lazin - 29.10.2007, 16:54

Да, конечно.


Ну эт очевидно, по моему .


Мне тоже не надо .

Можно, но только возможностей немного больше, в этом-то и проблема, возможностей дофига, и пользоваться ими можно поразному, но не все из того что можно есть гут

Возвращаясь к заявленной теме. В идеале каждую программу нужно делать как отказоустойчивую. На практике этого добиться не удается очень часто ( читай, - практически всегда). Но есть программы с требованиями повышенной "плавучести". В идеале, С++ должен предоставить для программиста соответствующие возможности. С наиболее простым вариантом - одиночным исключением все понятно. Исключение возбуждено, обработчик перехватил его, обработал, принял "соответствующие" меры и передал управление в программу (без аварийного завершения). Но, посмотрим, как все может произойти (обязательно произойдет) на практике. В блоке try - catch исключение. Прежде чем оно передается в блок catch(ESomeExceprion e), освобождаются локальные переменные. Для объектов вызываются их деструкторы. Я могу прописать в деструктор некоего объекта дополнительные действия помимо освобождения памяти. Например, возвращая контекст некоего устройства в прежнее состояние. Что происходит с обработкой предыдущего исключения, если в этот момент возбуждается новое?

Это сообщение отредактировал(а) akizelokro - 29.10.2007, 15:51

Вызывается std::terminate(), который в свою очередь std::abort().

Добавлено через 1 минуту и 34 секунды
Так что про "старое" исключение можно забыть, как и про всю программу.
Читаем классиков: деструктор не должен выпускать исключений!

  ИМХО зависит от самого блока catch, прежнее прервется, обработается новое, если нет своего перехватчика, то обработка предыдущего должна прерваться, если есть то продолжиться после окончания вложенного перехватчика.

Alexeis, читай выше - если во время отмотки стека вывалится ещё одно исключение, то вывалится вся прога.

archimed7592, если внутри catch сделать еще одну защищенную секцию, дальше если внутри этой вложенной секции опять возникнет исключение, что неужели не сработает catch это вложенной секции?

Здесь мне не все ясно. В книгах описания ситуации я не встречал. Но судя по принципам обработки, в этом случае получается ерунда. Второе исключение возбуждено в пределах try{}, оно "пропиливает" стэк, продолжая освобождать еще не освобожденные локальные объекты. После раскрутки стэка и перехвата исключения выполнение программы должно по идее перейти к следующей за try-catch блоком инструкции. Если же программа возвращается к обработке первичного исключения, то (предположу), что вновь будет предпринята попытка "раскрутки" стэка с непредсказуемыми последствиями  . Стэк уже единожды раскручен?
Также, где хранится "значение" для первичного исключения? В вершине стэка? 


Это я рассматриваю тот случай, когда на каждое из двух исключений есть свой обработчик, не завершающий выполнение программы. Либо catch(...) не отфутболивает с помощью throw() исключение по цепочке.

Это сообщение отредактировал(а) akizelokro - 29.10.2007, 16:30

На примере понятней будет?



Добавлено через 3 минуты и 2 секунды

Тебе цитату из стандарта привести, где написано что будет, если во время раскрутки стека вывалится исключение?
Чё демагогию разводить то?

Приведи. Я еще учебник не одолел, так что мне стандарт штудировать еще рано. А учитывая количество литературы, в которой я закопался, и то, что мою работу с меня никто не снимал, просто нет времени.   

archimed7592, я не вижу чтобы строчка 

Была в защищенной секции...

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

вот тогда что произойдет?

Возможно Alexeis, имел ввиду следующее:

млин, он меня опередил 0_o

Это сообщение отредактировал(а) Lazin - 29.10.2007, 17:01

если здесь возникнет исключение, тогда std::terminate().

Стандарт штудировать не обязательно... IIRC об этом же подробно написано у Мейрса.



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

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

Какая разница, если до неё выполнение даже не дойдёт .

Добавлено через 3 минуты и 32 секунды



Добавлено через 4 минуты и 34 секунды
А что ещё может произойти, если ошибка произошла в самом механизме обработки ошибок? 0_о

В Дельфи такого понятия нет, ибо там нет понятия "автоматический объект", как и нет RAII.

Добавлено через 6 минут и 3 секунды

Ну с этим всё понятно - а что, в Delphi вложенные блоки обрабатываются как-то иначе?

Вообще говоря, выполнение в блоке catch отличается от выполнения вне блока catch только тем, что внутри catch поведение инструкции throw; имеет предсказуемый результат.
Даже в таких, немного извращённых, случаях:

  Да я с исключениями знаком поверхностно. Примерно знаю как их юзать и все, как оно там внутри не вникал. Однако я ничего не слышал про то что внутри блока обработки нельзя вызывать другое исключение...

Внутри блока можно .

Когда генерируется исключение, все автоматические объекты из данной области видимости уничтожаются(называются отмоткой стека). Под уничтожением понимается отработка деструкторов. Это происходит ДО входа в блок catch. Т.о., если во время этой отмотки стека из одного из деструкторов вывалится исключение(наружу), то сработает terminate, поведение которого по умолчанию - abort(abnormal termination).

 Т.е. уничтожаются все статические объекты объявленные в этом блоке (в блоке try)?

Не статические, а автоматические . У статических объектов деструкторы отрабатывают по её завершению(грубо говоря, по выходу из main).
И не только те, что объявлены в этом блоке, но во всех других блоках видимости, которые покидает исключение по пути к своему обработчику.


Обрати внимание, что уничтожается не только 7, но 4, 3, ибо их область видимости тоже заканчивается во время проброса исключения и, соответственно, отмотки стека.

Добавлено через 2 минуты и 19 секунд
На принципе отмотки стека и основан RAII - это замена вашему finally(вместо него деструктор)... Только вот finally можно забыть написать, а деструктор автоматического объекта вызовется автоматически по выходу из области видимости . Будь то исключение, обычной ход выполнения, goto или ещё что-нибудь.

Это сообщение отредактировал(а) archimed7592 - 29.10.2007, 22:07

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

В делфях все не так работает. Если возникает исключение, то обработка происходит внутри текущего блока. Он как бы изолирован и не видит внешнего блока. Только если исключение будет в самой обработке, тогда вызовется внешний обработчик. Для блока Try может быть только 1 except или 1 finally (но не одновременно)

Пример


Сначала сработает finally, но сообщение 'выполнился finally' не выйдет, так как сгенериться AV и только в этом случае выполниться except.
Обработка разных типов исключений определяется в рамках одного блока, т.е. в данном случае 
"on EDivByZero       do showmessage('выполнился EDivByZero');" никогда не выполниться потому, что исключение EDivByZero считается уже отработанным в блоке finally.

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

За ответ спасибо. За ссылку на Мейерса тоже, но чтить его буду после одоления текущего учебника.

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

Вот и ответ автору темы на его поставленные вопросы (большинство из них).

А что ты понимаешь под словами "делаю всё правильно"?
Грубо говоря, зачем выпускать исключение из деструктора можешь объяснить? Ты же потом уже не сможешь уничтожить объект "до конца".

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



или с деструктором в функциональном виде, то даже несмотря на наличие обработки исключения, на которую я надеюсь, программа все равно отрубится. Согласно стандарту. Для динамических объектов это не так.



Это сообщение отредактировал(а) akizelokro - 31.10.2007, 11:36

Неправда. В C++ одновременно может быть хоть сто необработанных исключений. Если их вовремя ловить, то программа будет вполне себе благополучно работать.

В данном случае код вполне легальный.
Программа убивается через std::terminate(), когда исключение выходит за пределы деструктора!!!!
т.е.Результат работы будет следующий:

Добавлено через 2 минуты и 26 секунд
В данном примере, в деструкторе класса B было кинуто исключения типа const char *, а catch стоял только на исключения типа int. В итоге, исключение вышло из пределов деструктора, а так как деструктор не закончил выполнение, была вызвана std::terminate().

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

Это сообщение отредактировал(а) akizelokro - 31.10.2007, 13:02

Кстати, такой код 



в МSVC++ 6 добрался до благополучного завершения. Хмык, нужно садиться за английский.

потому, что все исключения обработаны коректно.


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

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

сразу 2 исключения, а это уже папандос...

Думаю стоит начать с русского: я не один раз упомянул о том, что для terminate исключение должно вывалиться из деструктора(наружу). Фантазируй поменьше и читай повнимательней.

C учетом того, что эксперты иной раз у нас да лопухнутся (ничего личного), я все-таки предпочитаю верить более надежным источникам. Если "exits using an exception" означает "вывалиться из деструктора(наружу)", то приношу свои извинения за назойливость.

Ок. Как можно выйти из ф-ции(коей деструктор тоже является)? Либо return, либо исключение. Здесь упомянут только второй вариант(выходит из деструктора из-за [неперехваченного] исключения).
Извинения принимаются, но будь любезен быть немного повнимательней, а если не знаешь английский, то верь наслово русскоговорящим "экспертам, которые лопухаются".

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

Иными словами, у стандарта совсем не дружелюбный интерфейс). "unhandled" в упомянутой строке нет, а в предыдущей есть.



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

Это сообщение отредактировал(а) akizelokro - 1.11.2007, 08:15

Извините пожалста, а как можно выйти из ф-ции из-за обработанного исключения?


Прошу у тебя прощения, если ты действительно считаешь, что я в чём-то виноват.


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


Да что ты говоришь? А это ты типа не заметил...

Цитата(akizelokro @  1.11.2007,  08:14 )

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

Бывают же такие неблагодарные создания... Вот если я чего-то не знаю - да я сто раз спасибо скажу, если меня чему-то научат(и буду совершенно искреннен). А ты всё выставишь так, будто тут все тебе обязаны и вообще, ты тут самый умный, просто на время "забыл" о чём идёт речь. Твоё конечно дело, но, блин, начинает раздражать(не первый топик в которым ты себя так ведёшь).



Угу. Только не компиляться, а разбираться.

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

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



, где деструктор находится в функциональном блоке try-catch. Этот код не компилится под MSVC++ 6 и BDS2006. мне удалось прокомпилить его под MSVS 2008 Beta2. Здесь действительно программа выходит из деструктора по исключению, даже несмотря на то, что исключение обрабатывается в деструкторе. В предыдущих твоих примерах программа могла выходить из деструктора только при необработанном исключении (есть разница). Сейчас terminate() вызывается. Здесь возможны два варианта:
-Beta версия и есть Beta версия
-генерировать исключения в деструкторах не рекомендуется (но это вообще другая песня).

Пока что я считаю исключения одним из самых муторных разделов C++ (моя субъективная оценка). К теме экспертов и их уровня возвращаться не хочу. Просто просьба прокомпилить код под другим компилером и ткнуть мне в нос результаты.

Это сообщение отредактировал(а) akizelokro - 1.11.2007, 10:12

хм...
А разве такой синтаксис допустим в С++ ???   


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

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

какие результаты?
исправь ошибку синтаксиса и все нормально работает в твоем примере

да

читаем внимательно стандарт


а ты нам не пудри!

весь в тебя

PS: akizelokro,совет остается в силе!

Вот такие два варианта кода




это не одно и то же.
В первом случае function-try-block, во втором - обычный try-block. И применительно к деструктору поведение получается разным.

Это сообщение отредактировал(а) UnrealMan - 1.11.2007, 11:35

Угу. В твоем первом случае согласно цитате из стандарта, приведенной комодератором (если я опять "неправильно" перевел  ), происходит выход из деструктора. Во втором случае выхода из функции в результате обработки не происходит (фантазирую дальше). Управление бы перешло на следующую инструкцию за блоком. Ну, с этим я уже разобрался. Просто вопросы-ответы переросли в стычку, а она завертелась вокруг фразы из стандарта


в которой не указывается явно "unhandled", но есть "exits".
Сорри, мне просто нужно сдавать тест, а на предварилке я по исключениям очень крупно влетел. Вот и пытаюсь хоть таким образом переварить кашу из исключений, которая заварилась у меня в голове   . Если бы я занимался этим втихаря, то у меня могло бы и не получиться сделать это оперативно. А тут, "напрягая" наших экспертов и используя для допинга спортивный азарт, мне удалось это сделать довольно быстро. 


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

Это сообщение отредактировал(а) akizelokro - 1.11.2007, 11:57

А за базар то придётся ответить .
Ткни пальцем, где ты об этом написал.






Ещё раз для тех кто в танке: как можно выйти из ф-ции, используя перехваченное исключение(не return)?
Приведёшь пример, получишь миллион плюсов в репу, лично моё наиглубочайшее уважение, а также, сможешь рассказывать внукам "я нашёл опечатку в стандарте и её исправили".
Это очень важный(в частности для твоего понимания "самого муторного раздела С++") вопрос в этом споре. Как только ты на него ответишь, так сразу у тебя отпадут все, задаваемые тобой в этом топике вопросы.


Ты считаешь нормальным вызывать негативное мнение о тебе у других участников форума только ради того, чтобы сдать какой-то там тест?
А ну ка, эксперты, поднапряглись и быстро всё ему объяснили - его величеству нужно тест сдавать! 

Daevaorn, MAKCim, давно ли это(и зачем) вас понизили до комодов? 0_о