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

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

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

Здесь можно читать только сильно возмущенным -> понимаю, многим лень это делать. описывать ошибки которые могут и не возникнуть. И проще знать что пишешь. нежели писать охотника за приведениями. Но тем не менее, более или менее серьезное ПО, имеющее надежды на поддержку (как я видел такие ПО) имеют какие то формы отчета, как отчет грамотного сотрудника перед хорошим начальством о проделанной или заваленной работе.

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

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

Мой выбор, который я сделал уже давно - банальная, максимально упрощенная  трассировка: _RPT, OutputDebugString, ASSERT, __debugbreak - это в принципе все, что мне требуется для адекватного сопровождения проекта. Еще есть один механизм, я о нем уже где-то писал: вывод отладочной информации в реальном времени на внешний сервер, в консоль на каждый процесс и своим цветом на каждый поток. Но это уже касается программирования сложных HPC-приложений.