Какими методами вы добиваетесь стабильности в вашем ПО (программном обеспечении)? В случае если есть какие-то неконтролируемые участки, за счет чего удается отыскать проблемы (больше вопрос адресован к разработчикам desktop приложений)? Прошу всех кому не лень, поделиться своим опытом, или мнением по данной проблематике. Приведу простой пример из жизни (почему этим стал интересоваться): имеется приложение, которое я отправляю, например, на тестирование конечным пользователям, естественно бесконтрольный развал приложения мягко говоря не совсем хорошо выглядит в глазах конечного пользователя и мне как разработчику никакой информации о причине такого поведения не дает.
Для себя я использую обработку исключений в определенных, критических участках кода, с целью:
1. Сделать частичную раскрутку стека, с выводом информации с log-файл
2. С возможностью контролируемого продолжение работы приложения в определенных ситуациях, когда это возможно
3. Использую глобальную обработку исключений, для выявления не перехваченных исключений, для контролируемого завершения приложения в случае непредвиденных обстоятельств.

В книгах много всего интересного написано, много всего прочитал, но хотелось бы узнать кто и как это все применяет на практике.

Просьба сильно не пинать, если тема не актуальна)))

а что подразумевается под "неконтролируемыми участками"?
я долгое время писала и поддерживала софт для Сбербанка - стоял на всех серверах во всех отделениях, это дохрена машин по всей стране. причём нужно было, чтобы всё работало на железе от 486-х до самых последних блейдов. от косяков гарантированно не спасает ничто. потому что у разных осей и железа могут быть всякие особенности. но в целом, чтобы облегчить себе жизнь, рекомендуется проводить тщательное тестирование, юнит-тесты всяческие, на краевые условия, стресс-тесты, тесты на стабильность, тестирование под разными осями и всё такое.

сейчас венда, например, позволяет собрать дамп при падении программы и его можно запросить у юзера и использовать для отладки, если прога была собрана с дебажной информацией. я так делаю, если идёт тестовая обкатка какого-то нового софта. у меня вот тестеры в Питере сидят, прислали дамп и я успешно косяк нашла. удобно, если есть возможность запросить у юзера дамп.

Под неконтролируемостью я понимаю места в коде где может произойти, например, исключение или что то нештатное, чего предварительно не ожидаешь и даже не предусматриваешь. (например, от оператора new можно ожидать bad_alloc, бывают участки кода где неизвестно чего ожидать от вызванных функций, я это имел ввиду). Правильно ли понимаю, что на бета-тестирование вы отправляете сборку с включенной дебаг инфой (сборка release + debug info) или же вы отправляете дебаг сборку (debug сборка целиком)?. Если второе, то тогда встает вопрос с производительностью. Например, у меня в приложении разница в работе определенных алгоритмов может быть более чем 10раз между debug и release версией билда.

Спасибо за отклик.

у стандартных функций все возвращаемые значения и эксепшны задокументированы. у серьёзных библиотек чаще всего тоже есть подробное описание, чего ожидать от функции. просто аккуратнее код писать когда код маленький, это не так уж сложно. главное, не оставлять это на "потом доделаю", а делать сразу для особо противных функций с возможными выбросами разнообразных экспешнов можно сделать обёртки и их использовать. я, например, иногда заворачиваю информацию в свой эксепшн и дальше кидаю уже его, чтобы потом не ловить весь зоопарк эксепшнов где-то глобально.
а так, чаще всего все такие неотловленные ситуации вылазят на граничных и стресс тестах.

для того, чтобы понять, где бага, достаточно релиза с отладочной инфой. а у себя нужно хранить ту самую сборку, которая отправлена юзеру, со всякой дебажной ерундой. в принципе, особой разницы нет, юзеру уходят только рабочие файлы, всё остальное бережно хранится на случай атомной войны (юзер звонит и говорит, что всё упало). вот тут надо, не закрывая сообщения об ошибке, залезть в task manager и там по правой кнопке на упавшем процессе сделать сохранение дампа. затем записать, куда он его сохранил (ибо сохраняет он его в глубокой заднице, куда есть доступ только с админскими правами) и потом туда лезть под админом и этот файл отправлять программисту. а студия его умеет открывать и прямо выдаёт в деталях стек и место падения. это под семёркой так, под другими вендами я уже не помню, там тоже как-то можно было дамп получить вроде.
ещё неплохо записывать модуль и смещение ошибки - это можно заюзать в disassembly, если есть та самая версия, которая отправлена юзеру. в окне дизассембирования по модулю и смещению тоже можно поглядеть, где бага произошла, но там уже без стека, а это менее информативно.
в релизе просто будет оптимизация и возможно будет сложнее понять, что произошло. но по стеку обычно можно догадаться, где проблема.
в общем, можешь просто написать прогу, которая генерит эксепшн и потренироваться с её отладкой в разных вариантах. сам увидишь разницу.

Спасибо за ценную информацию, очень полезно. Правда у меня сейчас крайне неудобная ситуация - большое кол-во готового кода который предстоит в подобную схему впихнуть, но это уже дело техники и время.

Есть еще 1 вопрос, по просмотру дампа. Сгенерил искуственную ситауцию падения (путем обращения через невалидный указатель к объекту определенного типа). Создал файл дампа. Открываю его и вижу только системные вызовы в стеке вызовов. Однако, если я нажму кнопку Debug после развала и продолжу дебажить из под студии - вижу стек своих билиотек в том месте где и произошел развал. В чем могут быть у меня грабли?

Интересно, а это кто-нибудь использовал?
http://code.google.com/p/google-breakpad/w...tedWithBreakpad
По описанию вроде интересно.

возможно, студия не может найти пути до pdb-файлов. я точно не помню, где именно (а проверить сейчас не могу, венды дома нет), но там при открытии файла дампа где-то нужно было указывать пути до этих файлов, чтобы студия могла найти имена юзерских функций. можно в инете пошукать, на тему файла дампа и путей до dbg.

вот, например, пишут, как это сделать в MSVS2008, но в 2010 там вроде точно так же всё:
http://social.msdn.microsoft.com/Forums/en...e3-1b12d6061321


да, вроде занятная штука. и на нескольких платформах поддерживается, как я понимаю. надо будет посмотреть, что за зверь.

посмотрел тему про минидампы, это интересно. У меня получаются полные дампы по 600Мб+ )) Очень тяжело такие перемещать.

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

Насколько я понимаю дамп, это слепок всей памяти занятой приложением. Если приложение проглот, вроде хрома или фаерфокса, то он и гагабайтным может быть.

С минидампами меня вот, что смущает. Насколько я понимаю отладочная информация в бинарнике зависит от обций сборки, от версий библиотек, возможно от версии компилятора. И если для винды, где распространяется бинарник, я смог бы держать у себя выдранную из него отладочную информацию. То непонятно что делать в линухе, где куча дистрибутивов с разными версиями всего.

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

Скорее всего так и есть. Это так называемый full dump по сути снимок памяти приложения со всеми вытекающими отсюда последствиями.