X> эта удобность может обойтись слишком дорого.
X> имени файла и строки, достаточно для выявления ошибки в 99%.

Слишком дорого? А как же лишние часы, потраченные на попытку понять причину возникновения ошибки, кол-во которых могло бы уменьшиться, если бы у программиста был call stack?

А чем такой подход лучше приведённого мной (я про вариант с наследованием от boost::exception, разумеется)?

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

FH>Слишком дорого? А как же лишние часы, потраченные на попытку понять причину возникновения ошибки, кол-во которых могло бы уменьшиться, если бы у программиста был call stack?

Есть разные подходы к вопросу...

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

FH>Сузить, но не сократить до минимума.
а еще, было бы здорово, если бы исключение само лечило причину своего выброса.

FH>Хотя, всё зависит от проекта.
а какая разница? используемая IDE не показывает вызывающих?

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

FH>Слишком дорого? А как же лишние часы, потраченные на попытку понять причину возникновения ошибки, кол-во которых могло бы уменьшиться, если бы у программиста был call stack?
мне не нужен call-stack.

Наилучшая практика — ПРОЕКТИРОВАТЬ обработку ошибок.
И по возможности — выделять это в отдельную подсистему, для полной инкапсуляции обработки.
Но так редко удается, хотя к этому надо стремиться.
Возможно, наилучшим решением был бы аспектно-ориентированный подход.
Но я не знаю подобных решений для С++.
Кто бы занялся?

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

LVV>Наилучшая практика — ПРОЕКТИРОВАТЬ обработку ошибок.
т.е. не использовать исключения, а использовать коды ошибок?

LVV>хотя к этому надо стремиться.
зачем?

Здравствуйте, niXman, Вы писали:
X>Здравствуйте, FrozenHeart, Вы писали:
FH>>Слишком дорого? А как же лишние часы, потраченные на попытку понять причину возникновения ошибки, кол-во которых могло бы уменьшиться, если бы у программиста был call stack?
X>мне не нужен call-stack.

Это лукавство, или я не увидел в вашем профиле емайла Чака Нориса?
Может я конечно и тупой, но мне часто и стек не помогает понять причину падения,
даже если есть полные дампы — не могу однозначно получить ответ почему упало
приложение,как повторить ситуацию в отладке и исправить.

Попробуйте зайдите под гостем в краш-колектор моей программки
54202 падения при этом они сгруппированы по стеку
https://crash-server.com/AppVersion.aspx?ClientID=ppa&AppVersionID=86
даже такая автоматизация не помогает локализовать все проблемы.

Год назад я задавал вопрос про одно падение, которое возникает рандомно и только на XP
http://www.rsdn.ru/Forum/winapi/4957569.1

Автор: PPA
Дата: 08.11.12

Ответа не получил.

Считаю, что стек падений может быть не нужен только в одном случае — вашим кодом никто не пользуется.

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

если в код вкралась какая-то нереально сложная ошибка — мы собираем продукт в релизе но с отладночной инфой, и запускаем его под дебаггером. дебагер заскриптован, и в случае чего-то неординарного — создает core-dump, сохраняет call-stack, аргументы функции, локальные переменные, и еще выполняет всякое что там в скрипте записано.
а в штатном использовании программы, ничего более чем file:line не нужно.

PPA>Считаю, что стек падений может быть не нужен только в одном случае — вашим кодом никто не пользуется.
есть три типа программистов:
1. хорошие.
2. плохие.
3. отрицающие, что они плохие.


зы
как пример, приведу ситуацию из реальной жизни. недели две назад закончил реализацию некоторого механизма зеркалирования и отката состояния группы игровых серверов. получилось ~30000 loc. код писал я сам. дебагер был использован один раз.
но, вы можете не верить, дело ваше.

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

X>если в код вкралась какая-то нереально сложная ошибка — мы собираем продукт в релизе но с отладночной инфой, и запускаем его под дебаггером.
кстати да, после того как в GCC добавили AddressSanitizer и UndefinedBehaviorSanitizer — думаю мы и вовсе перестанем использовать дебаггер для подобных случаев.

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

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

LVV>>Наилучшая практика — ПРОЕКТИРОВАТЬ обработку ошибок.
X>т.е. не использовать исключения, а использовать коды ошибок?
Нет.
Проектировать — это не значит закладываться на конкретную реализацию.
Это значит, что помимо всех правильных ситуаций в системе надо спроектировать и возможные неправильные.
А потом подумать об централизованной обработке.

LVV>>хотя к этому надо стремиться.
X>зачем?
Чтобы подобных вопросов не задавать на форумах...

X> если в код вкралась какая-то нереально сложная ошибка — мы собираем продукт в релизе но с отладночной инфой, и запускаем его под дебаггером. дебагер заскриптован, и в случае чего-то неординарного — создает core-dump, сохраняет call-stack, аргументы функции, локальные переменные, и еще выполняет всякое что там в скрипте записано.
X> а в штатном использовании программы, ничего более чем file:line не нужно.

Т.е. Вы дожидаетесь возникновения проблемы у клиентов, после чего, имея при себе лишь имя файла, название функции и строку, из которой было выброшено исключение, пытаетесь воспроизвести её на своих системах? А если воспроизвести не получится? А если вариантов вызова throw слишком много? А что, если они зависят от того, откуда именно Вы пришли в данную функцию? Не лучше ли было бы иметь при это хотя бы call stack?

X> мне не нужен call-stack.

Вам — нет, а вот кому-то другому вполне может пригодиться.

Кстати, кто-нибудь знает в итоге ответ на следующий вопрос:

FH> Нужна конструктивная критика данного подхода и ответ на следующий вопрос — видел, что некоторые при выбрасывании исключения добавляют к нему информацию об оригинальном типе исключения

FH>

FH> #define MY_THROW(Ex) \
FH>   throw Ex << base_exception::location_info(debug::location(__FILE__, BOOST_CURRENT_FUNCTION, __LINE__)) \
FH>            << base_exception::original_type_info(typeid((Ex)).name()) \
FH>            << base_exception::trace_info(debug::get_call_stack())
FH>

FH> Для чего это нужно? Разве typeid в catch-блоке не даст того же результата?

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

LVV>Это значит, что помимо всех правильных ситуаций в системе надо спроектировать и возможные неправильные.
контрактное программирование?

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

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

LVV>>Это значит, что помимо всех правильных ситуаций в системе надо спроектировать и возможные неправильные.
X>контрактное программирование?
Еще ДО.
Контрактное программирование — это конкретная технология реализации.
А тут в принципе надо решать вопрос: а что будет, если случится вот это?
В одних случаях — ничего страшного.
А в других — "ой, ребята, я пошла, мне что-то нехорошо...".
А сколько я видел проектов, нигде проектирования вариантов аварийных ситуаций в голову не приходит.
Инструменты проектирования не настаивают на этом.
Только в ДРАКОНЕ — обязательными являются побочные ветви. Так он и сделан в космической отрасли.

Здравствуйте, niXman, Вы писали:
PPA>>или я не понял как без стека узнать кто позвал метод...
X>эта информация не первостепенной важности.
X>зная где исключение было выброшено, позволяет сузить понимание причины его возникновения.

Пока не понимаю.

void *__CRTDECL operator new(size_t size) _THROW1(_STD bad_alloc)
        {       // try to allocate size bytes
        void *p;
        while ((p = malloc(size)) == 0)
                if (_callnewh(size) == 0)
                {       // report no memory
                static const std::bad_alloc nomem;
                _RAISE(nomem);
                }

Бросили исключение — std::bad_alloc.
файл new.cpp — номер строки 63 (VC++2010)

Какие ваши действия чтобы узнать кто собственно заказал слишком много памяти, или она действительно кончилась?

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

FH>Т.е. Вы дожидаетесь возникновения проблемы у клиентов
что значит "дожидаетесь"? у нас есть отдел тестирования. значит да, дожидаемся что у конечного пользователя ничего страшного не произойдет.

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

это же нелепый пример.

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

X>это же нелепый пример.
не могу представить, как такое может произойти у конечного юзера...
допустим, размер обрабатываемых программой абстрактных данных, приходит откуда-то извне, к примеру по сети в виде строки. но тогда тут должен быть валидатор, и это требование должно быть заложено в архитектуру.