Как отключить окно "C++ runtime error"?

[Антон (LogRus)]

Добрый день, Коллеги!

Есть тестовый модуль (юнит тесты и всё такое), тестовый модуль - консольное приложение, он иногда выбрасывает не обрабатываемое исключение, как следствие появляется сообщение  "C++ runtime error" с кнопкой "Ok" пока её не нажмёшь процесс не умирает.

Как отключить эту хрень?
А то фигня полная, консольное приложение отображает окно, особенно здорово, когда приложение запускается из "Планировщика задач" от имени другого пользователя.

[Джон]

Захучить виндовые окошки сообщений и фильтровать нужные или ваще все на время теста и возвращать IDOK.

[Malaja]

LogRus,
а в самом nunit-е ничего подобного нет?

[Антон (LogRus)]

Джон, как-то это не круто.
Malaja, nunit? неее, boost::test framework
ничего такого не видел, вообще он сам отлавливает все исключения и пишет, что тест провален, в теории, на практике не всегда.

[Антон (LogRus)]

Если верить msdn, то /SUBSYSTEM:Console, должно помочь, в тоже время наличие main вместо WinMain, вроде как делает эквивалентно /SUBSYSTEM:Console, но что-то я не заметил.

[zubr]

Самый лучший вариант, все таки найти источник исключения и устранить его (если это возможно). Ну и как вариант:
Запускать данный процесс из другого процесса, который будет делать TerminateProcess, получив от основного процесса, к примеру event, по окончании main.

[Джон]

Джон, как-то это не круто.

Аааа. Ну... дык. )

[Антон (LogRus)]

Кстати, проблема в тесте оказалась в другом (ну в данном конкретном), оказалось, что из потока который выполнял работу выбросилось CTRL+C, обработчик по умолчанию прокидывает сигнал на уровень скриптов запускающих тест, лечится переназначением обработчика сигнала.

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

[Антон (LogRus)]

Не выличилось
проклятый cmd всегда перехватывает CRTL+C

[Mayor]

Если верить msdn, то /SUBSYSTEM:Console, должно помочь, в тоже время наличие main вместо WinMain, вроде как делает эквивалентно /SUBSYSTEM:Console, но что-то я не заметил.

не поможет, уже давно проверял

попробуй обернуть код в main try catch

[Джон]

LogRus, собственно говоря то про что Ирина сказала. В некоторых тест-фреймворках есть специальные ф-ции для отлавливания системных сообщений об ошибке. Если у тебя такого нет, то придётся делать самому. А как ещё отловить системные диалоги, кроме как внедрения в систему? Думаю, что и упомянутые фреймворки делают это точно так же. Не знаю, что ты такого "некрутого" в этом усмотрел. Ведь это совершенно нормальная ситуация, когда ошибка исходит из самой системы, она должна появиться, а твой тест только подготавливает (провоцирует) её. Например, вдруг пропадает связь с принтером. Значит твоя программа должна чисто обработать такую ситуацию, но перед этим система показывает свою ошибку. Нормально пользователь закрыват окошко и программа работает дальше. При автоматическом тестировании эту ф-ю пользователя и должна взять на себя эта дополнительная прожка.  В принципе ты можешь даже ею управлять, чтобы она отвечала твоему юниттесту дескать всё хокей, система показала ошибку, а не просто перехватывать исключение. И это будет правильно. ИМХО разумеется.

[Антон (LogRus)]

Джон, почему не круто?
всё что я хочу, это что бы если я сказал в студии, что ПО консольное значит оно консольное и не надо мне подключать CRT выводящее окна, иначе оно не консольное, его нельзя использовать в скриптах и в связке со сторожем.

То, что это можно всё перехватить перенастроить, это всё понятно и трудностей никаких не представляет.

Ну в общем текущее решение для моего случая:
1. Временно заменён обработчик SIGINT в одном из тестов, на вывод сообщения и exit
2. Решено изменить механизм завершения системы, т.е. избавится от засылки SIGINT

[Джон]

Так нет, подожди. Тебя ж смущает системное сообщение об ошибке. Какая разница, консольное приложение или нет? Оно всё-равно покажется.

[Антон (LogRus)]

а вот нахрена? если в документации написано (msdn), что будет сделан вывод в stderr (это поведения для консольного приложения, абсолютно естественно)

консольное приложение априори не должно показывать окна, а если я его через ssh дёргаю, мне бошку расшибить на кнопку из консоли умудрится нажать? а админ сервера, как удивится при появлении сообщения от приложения которое работает через ssh от имени другого пользователя?

[Джон]

Эммм мы о разных вещах говорим. Твою проблему с нажатием кнопки я хорошо представляю, поэтому и предложил хук, как самое безгеморрное средство. Представь себе в дебрях некой superpuperwin32.dll в ф-ции Function1() есть строчка а ля if(error==TRUE) ::MessageBox(...); и твоё прожка так или иначе к ней обращается. Какое ей дело, кто её вызвал? Консольное приложение или оконное? Напрямую или через туеву хучу других динамически загруженых длл? Тобой управляемые потоки ты направляешь сам куда хочешь, а системные?

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

Я конечно не знаю, какие системные ресурсы ты задействуешь, что выскакивает сообщение. Может всё гораздо проще. Знаю у некоторых вещей, например у инсталлятора (msi) есть такие режимы подавления ошибок в silent режиме, но опять же спцифичных сообщений. Как раз для удалённой или массовой инсталляции. Но как продусмотреть ВСЕ случаи возникновения ошибки...

зы Тут вдруг подумалось, а винда-то какая? Win32 NT? Так у неё консоль это тоже окошко. Вот под 9х был режим "Перезагрузиться в" там уже был настоящий текстовый режим и консоль.

[Антон (LogRus)]

Джон, согласен самое простое, но хочется докопаться до сути.
к тому же один и тот же код работает в Linux и Windows
в общем нет у нас окон и всё тут. есть одно окно писанное под wxWidgets (опять Linux + Windows), да и то это просто интерфейс удалённого управления сервером.

итак. проблема решена:
1. /SUBSYSTEM:CONSOLE в линкере
2. /SUBSYSTEM:CONSOLE ВО всех используемых DLL, оказалось, что в паре dll, /SUBSYSTEM:WINDOWS
т.е. убедитесь, что все ваши компоненты используют нужную вам CRTLib

Т.е. всё работает согласно документации, если сами, где-то не лажали