Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Прочее";
Текущий архив: 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
6-1260249129
Dmitriy
2009-12-08 08:12
2013.03.22
Как написать Firewall


2-1339918135
Pcrepair
2012-06-17 11:28
2013.03.22
Структура кода при обработке текстов


10-1180345824
лесник
2007-05-28 13:50
2013.03.22
ms word


2-1331179586
Eeuwige Rouw
2012-03-08 08:06
2013.03.22
Совместимость приложения!


15-1330983917
osoed
2012-03-06 01:45
2013.03.22
Из DLL Visual Studio в DLL Delphi7





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский