try и __try - кто ловит больше исключений?
От: Аноним  
Дата: 10.05.06 09:17
Оценка: :))) :)
Почитав про разницу между try и __try, так и не понял, который из них поймает больше. Не хочу применять оба вида обработки исключений, надо бы выбрать один.
Re: try и __try - кто ловит больше исключений?
От: Аноним  
Дата: 10.05.06 09:49
Оценка: 1 (1) :))
Здравствуйте, Аноним, Вы писали:

А>Почитав про разницу между try и __try, так и не понял, который из них поймает больше. Не хочу применять оба вида обработки исключений, надо бы выбрать один.


А когда читал, сам не ловил исключения?
Re: try и __try - кто ловит больше исключений?
От: Cheburek Россия  
Дата: 10.05.06 19:05
Оценка: :)
Здравствуйте, Аноним, Вы писали:

А>Почитав про разницу между try и __try, так и не понял, который из них поймает больше. Не хочу применять оба вида обработки исключений, надо бы выбрать один.


А где Вы прочитали про __try? В стандартном языке таких словов нету
http://gzip.rsdn.org/tools/member.aspx?id=cheburek
Re[2]: try и __try - кто ловит больше исключений?
От: Аноним  
Дата: 10.05.06 19:06
Оценка:
Здравствуйте, Cheburek, Вы писали:

C>Здравствуйте, Аноним, Вы писали:


А>>Почитав про разницу между try и __try, так и не понял, который из них поймает больше. Не хочу применять оба вида обработки исключений, надо бы выбрать один.


C>А где Вы прочитали про __try? В стандартном языке таких словов нету


JScript?
Re: try и __try - кто ловит больше исключений?
От: Erop Россия  
Дата: 10.05.06 19:10
Оценка: -1
Здравствуйте, Аноним, Вы писали:

А>Почитав про разницу между try и __try, так и не понял, который из них поймает больше. Не хочу применять оба вида обработки исключений, надо бы выбрать один.


Вообще говоря __try ловит всё, что ловит try, но таким образом, что фиг обработаешь
Так что прийдётям применять оба. Каждый в своём месте.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[3]: try и __try - кто ловит больше исключений?
От: Cheburek Россия  
Дата: 10.05.06 19:19
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Cheburek, Вы писали:


C>>Здравствуйте, Аноним, Вы писали:


А>>>Почитав про разницу между try и __try, так и не понял, который из них поймает больше. Не хочу применять оба вида обработки исключений, надо бы выбрать один.


C>>А где Вы прочитали про __try? В стандартном языке таких словов нету


А>JScript?

А Вы собственно, смотрели. в какой форум писали?
http://gzip.rsdn.org/tools/member.aspx?id=cheburek
Re: try и __try - кто ловит больше исключений?
От: Mr. None Россия http://mrnone.blogspot.com
Дата: 11.05.06 05:12
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Почитав про разницу между try и __try, так и не понял, который из них поймает больше. Не хочу применять оба вида обработки исключений, надо бы выбрать один.


Если C++, то ВСЕГДА try, никаких __try или чего либо ещё — это для pure C и других языков. try/catch(...) поймает вообще всё что угодно (включая SEH, правда тип не удасться восстановить, чтобы восстановить тип SEH смотри ниже), если указана опция компилятора /EHa (вместо /EHs или /EHsс).
Чтобы преобразовать SEH к исключению C++ и ловить их не с помощью try/catch(...), а с помощью специфицированного имени исключения, можно использовать функцию _set_se_translator (за подробностями в MSDN или первого Рихтера).
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re[2]: try и __try - кто ловит больше исключений?
От: Erop Россия  
Дата: 11.05.06 10:11
Оценка:
Здравствуйте, Mr. None, Вы писали:

А>>Почитав про разницу между try и __try, так и не понял, который из них поймает больше. Не хочу применять оба вида обработки исключений, надо бы выбрать один.


MN>Если C++, то ВСЕГДА try, никаких __try или чего либо ещё — это для pure C и других языков. try/catch(...) поймает вообще всё что угодно (включая SEH, правда тип не удасться восстановить, чтобы восстановить тип SEH смотри ниже), если указана опция компилятора /EHa (вместо /EHs или /EHsс).

MN>Чтобы преобразовать SEH к исключению C++ и ловить их не с помощью try/catch(...), а с помощью специфицированного имени исключения, можно использовать функцию _set_se_translator (за подробностями в MSDN или первого Рихтера).

Это всё конечно интересно, но хотелось бы понять от чего же ВСЕГДА?

В VC есть поддержка SEH через __try, __finally, __except и т. д.
Вполне работоспособная.
Если ты не собираешься мигрировать с VC, то от чего бы не пользоваться?

p.s.
Минус-то за что? С чем не согласен? С тем, что try и __try надо использовать там, где надо, так как они не взаимозаменяемы?

Кстати в VC был такой глюк.
Если где-то написать что-то вроде:
BYTE* p = 0;
try {
   p = new BYTE[1024];
   foo(p);
} catch( ... ) {
   delete [] p;
   throw;
}
delete[] p;
, а внутни foo() бросят какое-нибудь SEH исключение, которое где-то снаружи преведённого кода обрабатывается и ему говорят "продолжай с того же места", то всё помрёт.
Такая вот неприятная петрушка.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[3]: try и __try - кто ловит больше исключений?
От: Mr. None Россия http://mrnone.blogspot.com
Дата: 11.05.06 10:48
Оценка: 4 (1)
Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Mr. None, Вы писали:


E>Это всё конечно интересно, но хотелось бы понять от чего же ВСЕГДА?


E>В VC есть поддержка SEH через __try, __finally, __except и т. д.

E>Вполне работоспособная.
E>Если ты не собираешься мигрировать с VC, то от чего бы не пользоваться?

Потому что так гласит писании от MS.
MSDN -> C Language Reference -> The try-except Statement
...

Note Structured exception handling works with C and C++ source files. However, it is not specifically designed for C++. You can ensure that your code is more portable by using C++ exception handling. Also, the C++ exception handling mechanism is much more flexible, in that it can handle exceptions of any type.
For C++ programs, C++ exception handling should be used instead of structured exception handling. For more information, see Exception Handling in the C++ Language Reference.

MSDN -> C/C++ Language Quick Reference -> try-except Statement
...

Note Structured exception handling works with Win32 for both C and C++ source files. However, it is not specifically designed for C++. You can ensure that your code is more portable by using C++ exception handling. Also, C++ exception handling is more flexible, in that it can handle exceptions of any type. For C++ programs, it is recommended that you use the new C++ exception-handling mechanism (try, catch, and throw statements).


Более детально ниже.

E>p.s.

E>Минус-то за что? С чем не согласен? С тем, что try и __try надо использовать там, где надо, так как они не взаимозаменяемы?

С тем что __try можно использовать в программе написанной на C++ — НЕЛЬЗЯ.

E>Кстати в VC был такой глюк.

E>Если где-то написать что-то вроде:
E>
E>BYTE* p = 0;
E>try {
E>   p = new BYTE[1024];
E>   foo(p);
E>} catch( ... ) {
E>   delete [] p;
E>   throw;
E>}
E>delete[] p;
E>
, а внутни foo() бросят какое-нибудь SEH исключение, которое где-то снаружи преведённого кода обрабатывается и ему говорят "продолжай с того же места", то всё помрёт.

E>Такая вот неприятная петрушка.
Открою вам страшную тайну — никакого глюка нет. Ясен пень помрёт — "delete[] p" в catch-секции уже выполнен... И SEH тут вам ничем не поможет — если вы освободите ресурс, а потом попробуете его снова использовать, фигня выйдет: SEH не реализует транзакционность. С EXCEPTION_CONTINUE_EXECUTION вообще нужно быть осторожным — там и без C++ приколов хватает: его поведение очень сильно зависит от компилятора, порцессоора, архитектуры и много чего ещё. За подробностями в Рихтера, там есть очень живой пример, как можнго вляпаться по самые нехочу.

Вот основная причина не использовать специфику SEH в программе на C++:
SEH может неправильно работать с ресурсами C++, SEH вообще о них ничего не знает — когда компилятор встречает директиву catch он вставляет код по очистке локального контекста — вызовы деструкторов всех локальных объектов в нужном порядке, в случае __except и __finally такого поведения не гарантирует даже MS; если же деструкторы таки вызовутся и вы используете EXCEPTION_CONTINUE_EXECUTION, то кирдык вашей программе (сами догадайтесь почему).
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re[4]: try и __try - кто ловит больше исключений?
От: Erop Россия  
Дата: 11.05.06 12:27
Оценка:
Здравствуйте, Mr. None, Вы писали:
E>>Минус-то за что? С чем не согласен? С тем, что try и __try надо использовать там, где надо, так как они не взаимозаменяемы?
MN>С тем что __try можно использовать в программе написанной на C++ — НЕЛЬЗЯ.
Э-э-э? Что бы это значило?
Вообще хотелось бы понять от чего нельзя использовать? Вроде как никто не запрещает

E>>Кстати в VC был такой глюк.

E>>Если где-то написать что-то вроде:
E>>
E>>BYTE* p = 0;
E>>try {
E>>   p = new BYTE[1024];
E>>   foo(p);
E>>} catch( ... ) {
E>>   delete [] p;
E>>   p = 0;
E>>   throw;
E>>}
E>>delete[] p;
E>>
, а внутни foo() бросят какое-нибудь SEH исключение, которое где-то снаружи преведённого кода обрабатывается и ему говорят "продолжай с того же места", то всё помрёт.

E>>Такая вот неприятная петрушка.
MN>Открою вам страшную тайну — никакого глюка нет. Ясен пень помрёт — "delete[] p" в catch-секции уже выполнен... И SEH тут вам ничем не поможет — если вы освободите ресурс, а потом попробуете его снова использовать, фигня выйдет: SEH не реализует транзакционность. С EXCEPTION_CONTINUE_EXECUTION вообще нужно быть осторожным — там и без C++ приколов хватает: его поведение очень сильно зависит от компилятора, порцессоора, архитектуры и много чего ещё. За подробностями в Рихтера, там есть очень живой пример, как можнго вляпаться по самые нехочу.
Даже если добавить выделенную строку, то всё равно не поможет
Причина тоньше.

MN>Вот основная причина не использовать специфику SEH в программе на C++:

MN>SEH может неправильно работать с ресурсами C++, SEH вообще о них ничего не знает — когда компилятор встречает директиву catch он вставляет код по очистке локального контекста — вызовы деструкторов всех локальных объектов в нужном порядке, в случае __except и __finally такого поведения не гарантирует даже MS; если же деструкторы таки вызовутся и вы используете EXCEPTION_CONTINUE_EXECUTION, то кирдык вашей программе (сами догадайтесь почему).

Теперь про ресурсы C++.
1) C++ исключения ц MS сделаны поверх SEHных, так что всё они гарантируют
2) Если сказать EXCEPTION_CONTINUE_EXECUTION, то свёртки стека не будет и вызова деструкторов не будет и вообще ничего не будет
3) А вот если сделать как я показал в примере, а потом повыше EXCEPTION_CONTINUE_EXECUTION, то будет ой-ё-ёй.
Поэтому надо аккуратно использовать. Вдумчиво. Если уж так хочется сделать то, что написано наверху, то надёжнее таки через __try __finally
Хотя ещё надужнее через scope_guard конечно
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[5]: try и __try - кто ловит больше исключений?
От: Mr. None Россия http://mrnone.blogspot.com
Дата: 11.05.06 13:03
Оценка:
Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Mr. None, Вы писали:

E>>>Минус-то за что? С чем не согласен? С тем, что try и __try надо использовать там, где надо, так как они не взаимозаменяемы?
MN>>С тем что __try можно использовать в программе написанной на C++ — НЕЛЬЗЯ.
E>Э-э-э? Что бы это значило?
E>Вообще хотелось бы понять от чего нельзя использовать? Вроде как никто не запрещает
Звините, но вы читать умеете? В предыдущем посте я английским по белому процитировал фразу из MSDN`а — "it is recommended that you use the new C++ exception-handling mechanism (try, catch, and throw statements)"... Ребята из Редмонта, знаете ли вообще никогда и ничего железно не запрещают (а если запрещают, то либо это не документируют, либо не экспортируют), но их "not recomended" надо читать именно как "MUST NOT BE USED". Знаете ли даже задепрекейченные методы и те помечены как "нерекомендованные к использованию"...

E>>>Кстати в VC был такой глюк.

E>>>Если где-то написать что-то вроде:
E>>>
E>>>BYTE* p = 0;
E>>>try {
E>>>   p = new BYTE[1024];
E>>>   foo(p);
E>>>} catch( ... ) {
E>>>   delete [] p;
E>>>   p = 0;
E>>>   throw;
E>>>}
E>>>delete[] p;
E>>>
, а внутни foo() бросят какое-нибудь SEH исключение, которое где-то снаружи преведённого кода обрабатывается и ему говорят "продолжай с того же места", то всё помрёт.

E>>>Такая вот неприятная петрушка.
MN>>Открою вам страшную тайну — никакого глюка нет. Ясен пень помрёт — "delete[] p" в catch-секции уже выполнен... И SEH тут вам ничем не поможет — если вы освободите ресурс, а потом попробуете его снова использовать, фигня выйдет: SEH не реализует транзакционность. С EXCEPTION_CONTINUE_EXECUTION вообще нужно быть осторожным — там и без C++ приколов хватает: его поведение очень сильно зависит от компилятора, порцессоора, архитектуры и много чего ещё. За подробностями в Рихтера, там есть очень живой пример, как можнго вляпаться по самые нехочу.
E>Даже если добавить выделенную строку, то всё равно не поможет
E>Причина тоньше.
Нет тут никакой тонкости, относительно того, кода, что вы написали причина именно в этом и C++ исключения тут не причём. От того что вы присвоите указателю 0-вое значение попытка его разыменования успехом не окончится. А там где действительно есть тонкость не поможет и SEH ибо он тоже валится, за подробностями к Рихтеру.

MN>>Вот основная причина не использовать специфику SEH в программе на C++:

MN>>SEH может неправильно работать с ресурсами C++, SEH вообще о них ничего не знает — когда компилятор встречает директиву catch он вставляет код по очистке локального контекста — вызовы деструкторов всех локальных объектов в нужном порядке, в случае __except и __finally такого поведения не гарантирует даже MS; если же деструкторы таки вызовутся и вы используете EXCEPTION_CONTINUE_EXECUTION, то кирдык вашей программе (сами догадайтесь почему).

E>Теперь про ресурсы C++.

E>1) C++ исключения ц MS сделаны поверх SEHных, так что всё они гарантируют
То что иногда C++ исключение реализуются с помощью SEH — это я в курсе (я даже примерный номер SEH исключения вам могу сказать: С0...05). Но!
vector внутри себя, знаете ли, тоже new вызывает, который в свою очередь HeapAlloc кличет, но это ещё не означает, что надо утверждать, будто бы HeapAlloc автоматически чистит память при выходе из локального контекста. Вызов деструкторов гарантирует только try/catch и всё. Если __try/__except где-то и вызывает их — это его личные проблемы. Простите, если бы try/catch топорно подменялись на __try/__except, то следуя логике вашего следующего высказывания при наличии ниже фильтра EXCEPTION_CONTINUE_EXECUTION catch вызваться не должен, но он вызывается, так что либо это утверждение не верно и try/catch содержит ещё что-то кроме замены на __try/__except, либо следующее утверждение ошибочно.

E>2) Если сказать EXCEPTION_CONTINUE_EXECUTION, то свёртки стека не будет и вызова деструкторов не будет и вообще ничего не будет

Интересно посмотреть, как это будет работать, если моё исключение случайно покинет пределы dll, будет перехвачено в вызывающем процессе и завёрнуто обратно с помощью EXCEPTION_CONTINUE_EXECUTION? Я конечно ничего не исключаю и может быть при вставке __exсept или __finally всегда наворочивается мегалогика по проходу стека туда и обратно в поисках наличия EXCEPTION_CONTINUE_EXECUTION с целью определения необходимости вызова деструкторов, но в таком случае знаете ли try/catch генерит более эффективный код — вот вам ещё один аргумент ЗА...

E>3) А вот если сделать как я показал в примере, а потом повыше EXCEPTION_CONTINUE_EXECUTION, то будет ой-ё-ёй.

Ещё раз подчёркиваю Ой-ё-ёй при использовании EXCEPTION_CONTINUE_EXECUTION может быть даже на чистом C с использованием одних только SEH и вот этот-то ой-ё-ёй как раз очень и очень тонкий...

E>Поэтому надо аккуратно использовать. Вдумчиво. Если уж так хочется сделать то, что написано наверху, то надёжнее таки через __try __finally

Писать знаете ли вообще надо вдумчиво — подумать, подумать и не использовать то, что не рекомендовано или не очевидно...

E>Хотя ещё надужнее через scope_guard конечно

Угу, только вот с SEH он может работать неверно... А то и вовсе не работать.
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Re[6]: try и __try - кто ловит больше исключений?
От: Erop Россия  
Дата: 11.05.06 16:09
Оценка:
Здравствуйте, Mr. None, Вы писали:

E>>Хотя ещё надужнее через scope_guard конечно

MN>Угу, только вот с SEH он может работать неверно... А то и вовсе не работать.
Ты это, о VC или о чём пишешь-то?
Постомтри просто как исключения там реализуются и как SEH.
Просто погляди что во что компилится да и всё. Чего ты на Рихтера тыкаешь?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[7]: try и __try - кто ловит больше исключений?
От: Mr. None Россия http://mrnone.blogspot.com
Дата: 12.05.06 02:57
Оценка:
Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Mr. None, Вы писали:


E>>>Хотя ещё надужнее через scope_guard конечно

MN>>Угу, только вот с SEH он может работать неверно... А то и вовсе не работать.
E>Ты это, о VC или о чём пишешь-то?
E>Постомтри просто как исключения там реализуются и как SEH.
E>Просто погляди что во что компилится да и всё. Чего ты на Рихтера тыкаешь?

О VC в том числе. И смотреть даже не буду что во что компилируется. То что исключения C++ реализуются через SEH — это я в курсе, речь не о том, а о том, что try/catch в общем случае не обязаны тупо преобразовываться в __try/__excpect (и, кстати, они и не преобразуются в тупую). Вы мне приведите цитату от производителя (от разработчиков MS VC), где он гарантирует поведение деструкторов при использования голых SEH точно такое же, как в случае try/catch, тогда я с вами может быть соглашусь, что иногда их можно применять. Пока что я видел только рекомендацию не использовать SEH в программах на C++.
А про Рихтера я упоминал в контексте проблемы использования EXCEPTION_CONTINUE_EXECUTION и ЧИСТЫХ SEH — этот фильтр сам по себе небезопасен, даже без C++ специфики, и его поведение сильно зависит от многих факторов (почитайте поймёте о чём речь, я бы процитировал, но там очень много)... Сам Рихтер, кстати, ничего против __try/__excpect не имел...
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.