Легенда:
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Достаточно часто для функции можно быть уверенным близко к... 07.03.09 00:27 Число просмотров: 2606
Автор: Heller <Heller> Статус: Elderman
|
> А при чем здесь память? Вообще то эксепшоны должны > выкидываться в ответ на любую непредвиденную ситуацию > (собственно эксепшон). Будь то access denied при открытии > файла или невалидные данные от юзера. bad_alloc - на самом > деле одно из самых редких исключений. Достаточно часто для функции можно быть уверенным близко к 100%, что она не кидает никаких эксепшенов. В том-то и дело, что bad_alloc - это тот самый эксепшен, который часто даже почти в тривиальной функции теоретически может возникнуть. Ну, допустим написал я функцию, которая внутри где-то у себя ресайзит вектор. И это единственное место где она может упать. Могу ли я писать throw() в декларации? Все же bad_alloc - штука крайне редкая, и в 99.99% приложений вообще никогда не встретится.
> Зато можно спасти бэдаллоком, который ГАРАНТИРОВАННО можно > бросить (в смысле стандарт требует, чтобы места под > объект-исключение bad_alloc хватало ВСЕГДА, даже когда на > все остальное памяти уже нет). И да, по unexpected ситуацию > вообще не спасешь - можно только сделать дамп памяти для > дебага или что то в том же духе. Независимо от того, > сколько у тебя памяти Я может быть слишком халатен, но мой подход таков: "Нет памяти, значит покупай железо". Память находится вне компетенции девелопера. На bad_alloc я просто плевал. Никак его не обрабатываю (кроме сообщения "купи памяти"), и даже не пытаюсь спасти рантайм. Пусть упадет хоть как - не мое дело. Но в то же время не смотря на мою халатность писать для функции throw(), если она работает с памятью, как-то уж даже для меня - слишком. Но с другой стороны почему бы и нет? Вот и колеблюсь.
> Ситуация не невозможная, а исключительная - разные вещи. > Исключительные ситуации вполне ожидаемы. Допустим я реализую что-то с указателями ("умные" не всегда подходят) - такое случается, бывает. И вот я отладил уже на 100% какую-нибудь функцию и уверен вообще совсем и полностью, что бага нет. Имею я право писать throw()? Или все же то что я уверен еще не значит, что я имею право на throw()? Таки и assert-ы бывает срабатывают.
> Аппаратные исключения кэтчатся не всегда: не всеми > компиляторами и не при любых настройках (насколько я помню > стандарт вообще ничего не говорит о том, как с ними > работать). В VC есть два способа: поставить se_translator > или catch(...) с асинхронными исключениями (/EHa) Ну да, я главным образом о Винде говорю.
> > 99% всего что пишешь. Мне конечно не сложно, но однако > ж. > Да Кстати, есть еще и чисто психологически момент: когда смотришь на объявление функции что-нибудь типа
ret_type getSomeStuff();
то ты спокоен. Когда же смотришь на объявление вроде такого:
ret_type getSomeStuff() throw(...);
то уже подходешь к функции более серьезно. Ну а если еще и конкретные эксепшены указаны - то вообще обработаешь каждый в отдельности с гораздо большей вероятностью, чем при "голом" объявлении.
> Ты ЧИВО? Эксепшоны ВООБЩЕ не предназначены для отлавливания > неправильной работы с указателями (для этого есть умные > указатели). Независимо от этого экспепшены сами по себе - > КРАЙНЕ полезная фича плюсов, а вот спецификации этих самых > исключений не используются практически нигде (кроме разве > что спецификации throw() ) Немного не так выразился. Но однако повторюсь, что нет-нет, да обычные опасные указатели все же приходится использовать. Добавь сюда работу со старыми библиотеками (никуда не денешься) и сопровождение старого кода. Под никсами можно обрабатывать сигналы, а под виндой единственственный вариант, какой я вижу - эксепшены. Указатели и аллокации я привел потому что это самые трудно контролируемые ошибки, которые сразу же приводят к падению, если грамотно их не обработать. С остальными ошибками все же как-то проще, согласись.
Кстати, еще одно преимущество использования throw() - дополнительные компиляторные оптимизации, которые могут быть произведены.
|
|
|