Тотальный контроль над исключениями

 
0
 
C++
ava
BearFear | 10.04.2013, 09:15
Всем КУ. Уважаемые, не хотелось бы разводить набор ссылок на тему аля "здесь читай и додумывай сам". Но и слишком изрядно напрягать таким вопросом никого не хочется. А вопрос такой.
Меня зовут Никита, и я использую свои хандлеры эксепшенов. *Давайте поприветствуем члена нашего кружка анонимных алкоголиков программистов*
Использую таким образом:
1 поток = 1 хандлер. На счет работоспособности вопросов нет, все работает (Я не говорил что нет ошибок! Знаю, есть любители придраться к словам.). Интересует более высокое положение относительно исключений в т.ч. виндусовых. Скажу сразу, данные возможности делались мной не на разовый проект, подобия "написал и забыл", а скорее всего на память. Написал - отложил в ящик - вспомнил - вытащил, нашлась ошибка - исправил. И меня интересует, есть ли ваще в природе такие люди, которые в первых строках кода свеой программы вешают обработчики (а так же делают это средствами ООП для повторного использования), а так же в иных потоках помимо главного. И эти обработчики ловят ВСЕ возможноые исключения и выводят наиподробнейшие сведения о произошедшем сбое.

Так же, интересно, если кто то делал или делает такие обработчики, то было бы здорово обменяться сырцами, для взаимного обмена опытом, а может даже и совершенствования вашего и моего кодов.

Сразу же напишу многа буков о том как сделал я в более подробном свечении. Сделал я так.
Имеется объект, которому указывается перформер. Этот перформер оберегается обработчиками исключений. Для главного потока, перформер является заменой мейна, а реальный мейн производит инициализацию объекта (речь об одном объекте и одном классе). Далее, сам объект, производит соответствующие вызовы WinAPI и пихает туда нуджный обработчик. Поскольку использования для логики не предусматривалось, такой обработчик делает тупо: побор регистров и вывод расшифровки кода исключения. Далее, полученный отчет направляется уже в синглтон репОртера. Тот в свою очередь, должен быть захвачен потоком и после получения заветных отчетов, выводит их в зависимости от указания сборки. Это может быть консоль и файл или только файл. Сам обект позволяет задействовать два типа ошибки. Логическая - это try catch, который возбуждает виндусовый exception подпихивая ему свой код и указатели на первичные сведения об ошибке. Логическая ошибка такого плана является критичной. На случай некритичных ошибок, имеется метод репОртера, который позволяет просто вывести сообщение об ошибке без заваливания приложения. И ошибка рантайма - это уже в случае если void(*bad_function)() = NULL; bad_function();
Срабатывает соответственно не всегда, но это уже особенность отлова исключений виндусом. Но все странности приложения, параллельно отслеживаются и коллстеком. Он по требованию выводится в логфайл и анализ сбоя начинает доставлять удовольствие. Скажу по статистике. Из найденных 10 сбоев, на каждый из них потребовалось минут 5 для их устранения, при этом не разу не запускался отладчик. Запускался в редчайших случаях трессировщик.

Здесь можно читать только сильно возмущенным -> понимаю, многим лень это делать. описывать ошибки которые могут и не возникнуть. И проще знать что пишешь. нежели писать охотника за приведениями. Но тем не менее, более или менее серьезное ПО, имеющее надежды на поддержку (как я видел такие ПО) имеют какие то формы отчета, как отчет грамотного сотрудника перед хорошим начальством о проделанной или заваленной работе.
Comments (1)
ava
mega | 12.04.2013, 07:46 #
Первый раз не голосовал, т.к. сначала не нашел пункта котороый мне ближе, но теперь понимаю, что надо было голосовать за "Ставлю обработчики только реально возникающих исключений", даже можно перефразировать так: "Ставлю обработчики для исключений, которые я реально нашел, и только те, которые нельзя обработать штатно"

В этом плане, мое мнение таково: обработчики исключений удобны в непредсказуемых случаях, например: когда Вы не знаете, что ожидать от кода. Для каких-то частных случаев - довольно удобно проинспектировать таким образом чей-то код. выявить его недостатки. Но в реальном приложении обработка исключений добавляет массу мишуры, которую приходится таскать за собой и под которую приходится подстраиваться.

Мой выбор, который я сделал уже давно - банальная, максимально упрощенная  трассировка: _RPT, OutputDebugString, ASSERT, __debugbreak - это в принципе все, что мне требуется для адекватного сопровождения проекта. Еще есть один механизм, я о нем уже где-то писал: вывод отладочной информации в реальном времени на внешний сервер, в консоль на каждый процесс и своим цветом на каждый поток. Но это уже касается программирования сложных HPC-приложений.
Please register or login to write.
Firm of day
Вы также можете добавить свою фирму в каталог IT-фирм, и публиковать статьи, новости, вакансии и другую информацию от имени фирмы.
Подробнее
Contributors
  mega   BearFear
advanced
Submit