Форум: "Прочее";
Текущий архив: 2013.03.22;
Скачать: [xml.tar.bz2];
ВнизОбработка исключений Найти похожие ветки
← →
Dimka Maslov © (2012-09-13 21:08) [0]Имеется некоторый объект. В его деструкторе надо различать нормальное его уничтожение от аварийного в результате исключения. В Delphi всё просто - я просто проверяю ExceptAddr, и если оно не nil, принимаю соответствующие действия.
Внимание вопрос: Есть ли что-то подобное в C++ (мелкомягком). Как известно, там деструктор вызывается неявно при выходе из контекста, в т.ч. по исключению. В MSDNе в разделе про обработку исключений, сказано про GetExceptionInformation. Но там же сказано, что это макрос и вызывать его надо только внутри блока обработки исключений, иначе возникнет ошибка компиляции. Другими словами, просто так в деструкторе его не вызвать.
Можно ещё конечно в класс добавить дополнительное поле, которому перед нормальным завершением работы присваивать другое значение, по которому в деструкторе и разделять ситуации. Но таких мест в коде тысячи их...
← →
брат Птибурдукова (2012-09-13 21:29) [1]
> В его деструкторе надо различать нормальное его уничтожение
> от аварийного в результате исключения
Есть мнение, что в консерватории что-то неладно.
← →
Dimka Maslov © (2012-09-13 21:34) [2]
> Есть мнение, что в консерватории что-то неладно.
Конечно неладно, раз исключение уже произошло
← →
Dimka Maslov © (2012-09-13 21:44) [3]Вопрос снимается, это std::uncaught_exception()
← →
Игорь Шевченко © (2012-09-14 00:08) [4]Есть мнение, что в консерватории что-то неладно
← →
Dimka Maslov © (2012-09-14 07:53) [5]
> Есть мнение, что в консерватории что-то неладно
Консервантами в буфете отравились. Это надо для отладки кода отладчика скриптового языка. Когда всё нормально, пофиг, что было в объекте. Но если произошло исключение, объекты должны перед своим уничтожением успеть передать куда следует данные о своём состоянии. Объектов много и заходить в каждый отладчиком - очень долго.
← →
KSergey © (2012-09-14 08:52) [6]> Dimka Maslov © (13.09.12 21:34) [2]
> Конечно неладно, раз исключение уже произошло
Исключение не есть "ненормальная ситуация" в общем случае, так что утверждать по наличию исключения сказать, что "что-то неладно" - это неправильно.
Поддержу, есть мнение, что в консерватории что-то неладно.
А можно описать как эта информация используется в приложении?
← →
sniknik © (2012-09-14 09:32) [7]> А можно описать как эта информация используется в приложении?
рискну предположить, на основании
> Это надо для отладки кода отладчика скриптового языка.
что "использование" заключается в выдаче сообщения от ошибки тому кто там что-то дописывает в скрипте.
← →
Компромисс © (2012-09-14 09:35) [8]
> Но если произошло исключение, объекты должны перед своим
> уничтожением успеть передать куда следует данные о своём
> состоянии.
Это не их дело - куда-то что-то передавать. Это дело кода, который использует данные объекты. Иначе получим объекты, которые нельзя повторно использовать.
← →
Dimka Maslov © (2012-09-14 10:44) [9]
> А можно описать как эта информация используется в приложении?
Я (лично я) являюсь а) разработчиком транслятора б) разработчиком скрипта в) пользователем скрипта. Исключения генерирую я сам (лично) через throw. Транслятор двухпроходный. За первый проход осуществляется компиляция в промежуточный код (как дерево объектов), на втором этапе - непосредственно выполнение. Для вызова подпрограмм организован стек. Ошибки при работе скрипта обрабатываются через исключения С++. Таким образом, сразу автоматически раскручиваются оба стека - интерпретатора и скрипта. В тот момент, когда исключение поймано и выдаётся сообщение об ошибке пользователю (то есть мне) надо видеть стек скрипта в том виде, в каком он был перед началом раскрутки. Возможные решения - делать дамп перед throw, ибо делать дамп в catch - увы поздно. Проблема в том, throw вызывается из большого количества мест, в которых может и не быть доступа к стеку скрипта. Получается гораздо проще если отслеживать в деструкторах объектов наличие необработанного исключения и делать дамп самого себя перед уничтожением. При нормальном же завершении работы (вызов деструктора при штатном выходе из контекста никаких дополнительных действий принимать не надо. Если бы всё было написано на Delphi, где деструктор объекта вызывается явно, такой проблемы бы не возникло. И повторно использовать объекты мне не надо. И переделывать архитектуру, которой уже 13 лет я не собираюсь. Просто с годами растёт сложность скриптов, что требует их отладки.
← →
KSergey © (2012-09-14 20:01) [10]Ничего не понял, правда я трансляторов не писал, видимо поэтому не в теме.
Страницы: 1 вся ветка
Форум: "Прочее";
Текущий архив: 2013.03.22;
Скачать: [xml.tar.bz2];
Память: 0.48 MB
Время: 0.053 c