информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Атака на InternetВсе любят медSpanning Tree Protocol: недокументированное применение
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Блокировка российских аккаунтов... 
 Отзыв сертификатов ЦБ РФ, ПСБ,... 
 Памятка мирным людям во время информационной... 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Достаточно часто для функции можно быть уверенным близко к... 07.03.09 00:27  Число просмотров: 2311
Автор: 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() - дополнительные компиляторные оптимизации, которые могут быть произведены.
<programming> Поиск 






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2022 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach