Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
У меня нет под рукой сейчас исходников (не держу дома :-)),... 07.03.09 11:14 Число просмотров: 2395
Автор: Heller <Heller> Статус: Elderman
|
> Вот тебе ЦИТАТА из ISO/IEC 14882
У меня нет под рукой сейчас исходников (не держу дома :-)), но что-то мне подсказывает, что они и для empty() не объявляют throw(). Хотя могли бы. Это скорее вопрос исторический.
> Такое "бывает" разве что в third-party коде. Ты еще и за
> него отвечать хочешь?
Не вижу большой трудности:
catch(...) {
writeLog("Упало здесь");
throw MyOwnException();
}
> Имеешь право. Вот только я не вижу особой разницы между
> unexpected(), если ты сфейлил свои спецификации и
> terminate(), если ты просто не словил исключение. Если же
> ты собираешься сделать set_unexpected и перебрасывать там
> валидное исключение, то стоит вспомнить, что у тебя один
> unexpected_handler на всю программу и надо сделать его
> очень умным, чтобы переброшенное исключение соответствовало
> всем спецификациям.
Разница в том что имеет разработчик, который будет жергать функции моего класса.
[skipped, ибо в целом согласен]
> Да, но ты его видишь СОВЕРШЕННО не там. Никакие
> спецификации исключений не помогут тебе отловить
> разыменование нулпоинтера (буду повторять, пока ты не
> осознаешь :-) ).
Не осознал. Пользователь нажал на кнопку. В обработчике попытался разыменоваться нулл-поинтер. Я словил эксепшен. В функции, где это непосредственно произошло - отписываю в лог, что "вот здесь упало", а наверх пробрасываю типизированный эксепшн по которому могу уже принять какое-то решение (например, извиниться за ошибку в данном конерктном функционале, но продолжить работу всей остальной программы).
> Не согласен. Неинициализированные переменные или ошибки
> синхронизации гораздо хуже. Ошибка доступа к памяти
> мгновенно вываливает тебя в дебаггер и вся поднаготная
> ошибки у тебя на виду. Нехватка памяти - вообще не ошибка,
> ее действительно можно не обрабатывать.
Ну да. Здесь больше зависит от того, над какими проетами работаешь и от стиля программирования (у меня лично неинициализированных переменных вообще не бывает - как-то наловчился, а с многопоточностью я почти не работаю).
> http://www.gotw.ca/publications/mill22.htm (+ссылки в конце
> http://www.boost.org/development/requirements.html#Exceptio
Интересно. Да, таки многое стало понятнее.
Вывод, какой я сделал: либо throw(...) в качестве меты, если хочу дополнительно подчеркнуть, что к функции надо отнестись внимательнее, либо throw() для случая совсем банальных функций типа getsize() в целях оптимизации (см. мой ответ выше по ветке).
|
|
|
подробно о проекте
Анализ криптографических сетевых...
