Перехват системных исключений в С++

Ты ему только про Деда Мороза не говори, ок? :)

Возможно, использую библиотеку segvcatch в своих проектах. Она даже немного кроссплатформенна - работает для x86/x86-64 под Linux и Windows.

Эт не значит, что стремиться не надо :)

Я его видел. В Великом Устюге %) А еще - в степи под Саратовом под новый год. Когда у «приданых сил и средств» с утра и до наступления темноты одна задача: нарубить дров при помощи лома и тупой пилы, а ночью - борьба со сном дежурного по печке :) Что вы мне еще можете про этого персонажа рассказать?

Отсыпь чудо травы...

По поводу тестов. Писать их конечно нужно, но без фанатизма. Нужно следовать TDD в написании кода, но покрывать тестами все что только можно - глупая трата времени.

Почему тесты не дают гарантии безглючности:

1. Они в большинстве случаев исполняются на узком круге оборудования.

2. Тесты сами могут иметь ошибки.

3. Тесты иногда не могут покрыть весь функционал.

Отсыпь чудо травы...

Чемодан, вокзал, военкомат :)

Летом кстати, сам можешь собрать - на траншеях от «полевых занятий по добыче кабеля» - в человеческий рост. Только особист бдит, собака.

глупая трата времени.

любимая отмазка тех, кого хотят напрячь написанием тестов :)

можно конечно так сделать, запустить бесконечный скрипт, прога падает и скрипт перезапускает процесс - спроси меня как такие костыли делать, я тебя научу плохому :)

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

для меня крайне актуально! будь добр, поясни, какими средствами программы оборачиваются для получение отчетов?

вот в KDE да, правильно пояснили, что при падении программы просит прислать отчет

меня интересует применительно к Linux - чем можно обернуть софтину чтобы при падении хотя бы backtrace посмотреть?

я бы порекомендовал глянуть это http://code.google.com/p/google-breakpad/wiki/ProcessorDesign

и это http://en.wikipedia.org/wiki/Crash_reporter

Или посмотреть исходники DrKonqi (из KDE)

Или вот небольшой пример: http://ideone.com/HBAYU (компилять с опциями -g -fPIC)

подобную функцию можно повесить на обработчик сигнала SIGSEGV

В КДЕ есть например отчет об ошибках, в том числе там бектрейс есть. Можно там почитать прежде чем отправлять там диалог специальный показывает.

Хорошо, вот кокретный пример (за форматирование не бить):

#include <iostream>
#include <exception>
using namespace std;
int main(void)
{
int a = 0, b = 1, c;
try {
c = b/a;
cout << "c = " << c << endl;
}catch(exception exc)
{
cout << "Alarm!" << endl;
}
return 0;
}

Как следует переписать этот код, чтобы выводилось «Alarm!»?

Как следует переписать этот код, чтобы выводилось «Alarm!»?

man 2 signal/sigaction, например:

#include <csignal>

void handler(int a)
{
    /* do something and exit */
}

int main()
{
    signal(SIGFPE, handler);
    // ...
}

А средствами С++? try/catch сработает?

Коряво.

Попробуй посмотреть старенькую книжицу:

Теренс Чан. Системное программирование на С++ для Unix. — Киев: BHV, 1997.

Конечно, многое там уже «окаменело», но думаю, что про обработку сигналов может и пригодиться — «Глава 9. Сигналы».

Спасибо. После обработки исключений в Java многое непривычно и неудобно.

А средствами С++? try/catch сработает?

Можно ловить bad_alloc для new - new часть рантайма. Деление на ноль - UB по стандарту и должно обрабатываться системными средствами, в случае POSIX - signal/sigaction. Можно конечно попробовать сделать throw в handler, сделать handler методом специального класса который будет устанавливать signal в конструкторе, унаследовать свои ошибки от std::runtime_error и «ловить» деления на ноль и сегфолты в try/catch, но зачем? И где гарантия, что рантайм правильно отработает исключение при сегфолте? Гарантия того что хендлер будет вызван даётся системой.

Деление на ноль - UB по стандарту

Ужас.