Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Хых. Ты должен гарантировать это не только для самой... 07.03.09 03:03 Число просмотров: 3230
Автор: amirul <Serge> Статус: The Elderman
|
> Достаточно часто для функции можно быть уверенным близко к
> 100%, что она не кидает никаких эксепшенов. В том-то и
Хых. Ты должен гарантировать это не только для самой функции, но и для всего кода, который может быть достигнут, не выходя из нее (функций любого уровня вложености, которые она вызывает даже косвенно). Для любой нетривиальной функции "задолбаешься пыль глотать".
> дело, что bad_alloc - это тот самый эксепшен, который часто
> даже почти в тривиальной функции теоретически может
> возникнуть. Ну, допустим написал я функцию, которая внутри
> где-то у себя ресайзит вектор. И это единственное место где
> она может упать. Могу ли я писать throw() в декларации? Все
Зачем?
Вот тебе ЦИТАТА из ISO/IEC 14882
23.2.6 Class template vector [vector]
void resize(size_type sz);
void resize(size_type sz, const T& c);
---
Видишь где нибудь спецификацию? Тебе ничего не обещают, а ты значит рвешься пообещать.
> же bad_alloc - штука крайне редкая, и в 99.99% приложений
> вообще никогда не встретится.
Я о том и говорил. Бэдаллок - это не тот эксепшн, который надо принимать в рассчет в первую очередь
> Я может быть слишком халатен, но мой подход таков: "Нет
> памяти, значит покупай железо". Память находится вне
> компетенции девелопера. На bad_alloc я просто плевал. Никак
> его не обрабатываю (кроме сообщения "купи памяти"), и даже
> не пытаюсь спасти рантайм. Пусть упадет хоть как - не мое
И не надо спасать - просто не лови (если не собираешься) и не специфицируй - неотловленное исключение на выходе из main все так же прибьет твое приложение.
> дело. Но в то же время не смотря на мою халатность писать
> для функции throw(), если она работает с памятью, как-то уж
> даже для меня - слишком. Но с другой стороны почему бы и
> нет? Вот и колеблюсь.
Не пиши.
> > Ситуация не невозможная, а исключительная - разные
> вещи.
> > Исключительные ситуации вполне ожидаемы.
> Допустим я реализую что-то с указателями ("умные" не всегда
> подходят) - такое случается, бывает. И вот я отладил уже на
Такое "бывает" разве что в third-party коде. Ты еще и за него отвечать хочешь?
> 100% какую-нибудь функцию и уверен вообще совсем и
> полностью, что бага нет. Имею я право писать throw()? Или
> все же то что я уверен еще не значит, что я имею право на
> throw()? Таки и assert-ы бывает срабатывают.
Имеешь право. Вот только я не вижу особой разницы между unexpected(), если ты сфейлил свои спецификации и terminate(), если ты просто не словил исключение. Если же ты собираешься сделать set_unexpected и перебрасывать там валидное исключение, то стоит вспомнить, что у тебя один unexpected_handler на всю программу и надо сделать его очень умным, чтобы переброшенное исключение соответствовало всем спецификациям.
> > Аппаратные исключения кэтчатся не всегда: не всеми
> > компиляторами и не при любых настройках (насколько я
> помню
> > стандарт вообще ничего не говорит о том, как с ними
> > работать). В VC есть два способа: поставить
> se_translator
> > или catch(...) с асинхронными исключениями (/EHa)
> Ну да, я главным образом о Винде говорю.
Ну дык и используй se_translator, собственно спецификации исключений тебе ВООБЩЕ не помогут в случае с разыменованием null-поинтеров. Более того, в транслированном эксепшоне ты можешь иметь всю информацию, которая вообще доступна в SEH. На всякий случай напомню, что SE транслятор ставится не на весь рантайм, а на поток, так что надо их ставить во все потоки, где ты ожидаешь выбрасывания SEH-исключений.
> > > 99% всего что пишешь. Мне конечно не сложно, но
> однако
> > ж.
> > Да
> Кстати, есть еще и чисто психологически момент: когда
> смотришь на объявление функции что-нибудь типа
> ret_type getSomeStuff();
> то ты спокоен. Когда же смотришь на объявление вроде
> такого:
> ret_type getSomeStuff() throw(...);
> то уже подходешь к функции более серьезно. Ну а если еще и
> конкретные эксепшены указаны - то вообще обработаешь каждый
> в отдельности с гораздо большей вероятностью, чем при
> "голом" объявлении.
У нас и так непростая работа, чтобы мучать себя еще и этим :-)
> Немного не так выразился. Но однако повторюсь, что нет-нет,
> да обычные опасные указатели все же приходится
> использовать. Добавь сюда работу со старыми библиотеками
А я не говорю, что надо везде использовать смартпоинтеры. Просто когда ты работаешь с неумными, и бросаешь хардварный эксепшн, плюсы вообще НИЧЕМ тебе помочь не могут. Ни эксепшоны, ни их спецификации не приспособлены для вылавливания таких ситуаций. Так что или умные указатели или упавшая программа (можно еще использовать расширения данной конкретной реализации для вылавливания хардварных исключений).
> (никуда не денешься) и сопровождение старого кода. Под
> никсами можно обрабатывать сигналы, а под виндой
Хых. Из хэндлера сигналов у тебя есть либо long_jmp либо exit. В VC же можно транслировать "сигналы" в обычные плюсовые исключения и работать с ними как обычно.
> единственственный вариант, какой я вижу - эксепшены.
Да, но ты его видишь СОВЕРШЕННО не там. Никакие спецификации исключений не помогут тебе отловить разыменование нулпоинтера (буду повторять, пока ты не осознаешь :-) ).
> Указатели и аллокации я привел потому что это самые трудно
> контролируемые ошибки, которые сразу же приводят к падению,
> если грамотно их не обработать. С остальными ошибками все
> же как-то проще, согласись.
Не согласен. Неинициализированные переменные или ошибки синхронизации гораздо хуже. Ошибка доступа к памяти мгновенно вываливает тебя в дебаггер и вся поднаготная ошибки у тебя на виду. Нехватка памяти - вообще не ошибка, ее действительно можно не обрабатывать.
> Кстати, еще одно преимущество использования throw() -
> дополнительные компиляторные оптимизации, которые могут
> быть произведены.
Хыхы. Скорее ДЕоптимизации.
http://www.gotw.ca/publications/mill22.htm (+ссылки в конце статьи)
И небольшая цитата от разработчиков буста (эх, может я когда нибудь и буду знать плюсы так как они):
http://www.boost.org/development/requirements.html#Exception-specification
"For example, some compilers turn off inlining if there is an exception-specification. Some compilers add try/catch blocks. Such pessimizations can be a performance disaster which makes the code unusable in practical applications.
Although initially appealing, an exception-specification tends to have consequences that require very careful thought to understand. The biggest problem with exception-specifications is that programmers use them as though they have the effect the programmer would like, instead of the effect they actually have.
A non-inline function is the one place a "throws nothing" exception-specification may have some benefit with some compilers."
|
|
|
подробно о проекте
Анализ криптографических сетевых...
