Qt: QThread ?

Детонька, может ты сначала на википедии прочитаешь о том, что такое исключения, а потом уже будешь шить белыми нитками к ним всё, что ни попадя? ;)

> Да. Тогда ты должен знать ВЕСЬ код

Если есть документация, то это, как правило, не проблема. Бросаемые исключения должны быть документированы.

> Дяденька, вы сделайте malloc 16 гигабайт с включенным overcommit, забейте эту память нолями, а потом «разговаривайте об исключениях».

Леди, в этом случае не будет исключения. Будет SIGSEGV или что-то в этом духе. А сигнал — это не то же самое, что исключения, по крайней мере в C++. Я не говорю сейчас о SEH и прочих приблудах.

> А сигнал — это не то же самое, что исключения

Ну нельзя же так грубо с дамой? Она может обидиться, заплакать и убежать.

*?!

Будет SIGSEGV или что-то в этом духе. А сигнал — это не то же самое, что исключения, по крайней мере в C++

Давайте сравним?

Необработанные сигналы sigsegv, sigfpe приводят к прекращению работы программы.

Необработанные исключения RTTI (в C++) и необработанные исключения в Java к прекращению работы программы.

После обработки сигналов sigsegv, sigfpe работа программы может быть продолжена.

После обработки исключений RTTI (в C++) или обработки исключения в Java работа программы может быть продолжена.

Ничего странного не видите? Сигналы это инструмент организовать зачаточный IPC и хоть какую-то обработку исключений. То что метод «RTTI через сигналы» неудобен, лишь следствие примитивности языка C и ограниченности ресурсов в стародавние времена, когда полноценная обработка исключений была слишком дорогой. Пора вылезать из убежища 101, мир давно изменился - exception может быть выброшен в любой момент, любой exception может быть обработанв компиляторах для «альтернативной платформы» трансляция исключений ОС в языковые конструкции давно уже реальность. Да и в линуксе и GCC также:

#include <string.h>
#include <iostream>
#include <stdexcept>
#include <unistd.h>
#include <signal.h>
#include "x86_64-signal.h"

static void unblock_signal(int signum __attribute__((__unused__)))
{
    sigset_t sigs;
    sigemptyset(&sigs);
    sigaddset(&sigs, signum);
    sigprocmask(SIG_UNBLOCK, &sigs, NULL);
}

SIGNAL_HANDLER(catch_segv)
{
    unblock_signal(SIGSEGV);
    MAKE_THROW_FRAME(nullp);
    throw std::runtime_error("Segmentation fault");
}

SIGNAL_HANDLER(catch_fpe)
{
    unblock_signal(SIGFPE);
    HANDLE_DIVIDE_OVERFLOW;
    throw std::runtime_error("Floating-point exception");
}

void setup() {
        INIT_SEGV;
        INIT_FPE;
}

int main() {
        setup();
        int i=1, j= 0;
        try { int n = i/j; } catch (...) { std::cout<<"Ops, FPE?!\n"; }
        try { *(int*)0 = 0; } catch (...) { std::cout<<"Ups, SEGV!\n"; }
        std::cout<<"I'm alive!\n";
        return 0;
}

Может, сначала Вы сначала сами пойдете и почитаете? Например, http://ru.wikipedia.org/wiki/Обработка_исключений, разделы про асинхронные исключения, а также про структурную и неструктурную обработку исключений ? Как-то грустно, когда «дяденьки» не способны отличать платформу, язык и концепцию.

>Вопрос сложный. Он имхо того же типа, что и бросание исключений в деструкторе.

Исключения в деструкторе приводят к остановке(если не предпринимать ни каких действий) программы. Так что здесь уже надо смотреть от задачи.

Ожидание - это скорее операция завершения, чем деструкурирование.

На деструктор возлагаются функция подчистки используемых ресурсов. Вот поток можно принять за ресурс и от него надо корректно избавится. Без функции wait скорее всего не возможно это сделать корректно.

А если кто нить в этот момент попросит из того потока при завершении основной поток? замкнутый цикл.

Такую проблему можно получить если функция wait будет не в деструкторе, так что это не аргумент.

>Деструктор - это всегда освобождение занятых ресурсов, а не ожидание, когда они сами освободятся.

Вот поток и есть ресурс, для его корректного освобождения скорее всего нуже вызов функции wait.

> Как-то грустно, когда «дяденьки» не способны отличать платформу, язык и концепцию.

Кот бы говорил! Грустно, когда этого не могут сделать деточки, и лезут в обсуждение языка, с деталями платформы. Если ты до сих пор не понял(а), мы обсуждаем(-ли) исключения в языке программирования С++. Ага?

Например, http://ru.wikipedia.org/wiki/Обработка_исключений, разделы про асинхронные исключения

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

А ну-ка выбори-ка исключение на плюсах по причине отключения питания! В рамках стандарта языка, разумеется. :3

> А ну-ка выбори-ка исключение на плюсах по причине отключения питания!

Если не передергивать, то неожиданный shutdown и его следствия в виде SIGTERM и SIGHUP вполне себе обрабатываются. Возьмите в качестве примера например код сферического демона на абстрактном линуксе в вакууме, как вы тут любите говорить: для него сигнал TERM или HUP, которые могут быть получены в любой момент времени, могут (и должны) транслироваться в языковые конструкции для последующей корректной обработки (exception-driven logic).

исключения в языке программирования С++

Извините, но обсуждать обработку исключительных ситуаций в C++ и одновременно с этим предполагать, что исключения порождаются в строго определенных разработчиком местах... Как дети в младших группах детского сада, закрыли глаза руками и радость: «А я в домике»

> Если не передергивать, то неожиданный shutdown и его следствия в виде SIGTERM и SIGHUP

Если не передергивать, то в механизме исключений языка С++ нет ни SIGTERM, ни SIGHUP.

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

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

> После обработки сигналов sigsegv, sigfpe работа программы может быть продолжена.

С той разницей, что обрабатывать SIGSEGV может быть себе дороже. В простом случае типа null pointer dereferencing — да, обработка SIGSEGV «спасёт» программу. Но в случае повреждённого стека, повреждённой памяти и прочих радостей можно сделать только хуже.

И не забывайте, что

According to POSIX, the behavior of a process is undefined after it ignores a SIGFPE, SIGILL, or SIGSEGV signal that was not generated by kill(2) or raise(3)

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

> Да и в линуксе и GCC также

А Вы уверены в переносимости данного метода? В том, что он будет работать на других компиляторах? Я видел похожую библиотеку на Google Code (названия сейчас не вспомню, но можно поискать), она использовала похожий подход — там были выдернуты какие-то файлы из gcj, и сигналы таким же образом преобразовывались в исключения. Но проблема была в том, что работало оно не везде.

Вот что получилось при сборке и выполнении:

$ g++ test.cpp -O2 -o test
$ ./test
terminate called after throwing an instance of 'std::runtime_error' what(): Segmentation fault
Аварийный останов

Если собрать с -fnon-call-execeptions, то работать будет, но…

-fnon-call-exceptions: Generate code that allows trapping instructions to throw exceptions. Note that this requires platform-specific runtime support that does not exist everywhere. Moreover, it only allows trapping instructions to throw exceptions, i.e. memory references or floating point instructions. It does not allow exceptions to be thrown from arbitrary signal handlers such as «SIGALRM».

Иными словами, 1) это не переносимо, 2) SIGHUP/SIGTERM Вы так не обработаете.

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

трансляция исключений ОС в языковые конструкции давно уже реальность

Signals and exceptions don't mix well, and should be considered seperately. While you can define an exception-based “wrapper” for signals, such code is not portable, because C++ does not guarantee that a signal-handling function is able to interact with any other part of a program. Creating a signal handler that throws an exception, for example, is undefined behavior in Standard C++.

QED

> Именно так, иначе это не разработчик, а долбодятел

Проявите себя как не-долбодятел, предложите как застраховаться например от «внезапного» исключения в приложении, которое взывает внутри себя проприетарную libpkcs11xxx? И еще один вопрос ниже пояса - что, разные компиляторы уже научились совместимым образом генерировать совместимый код для исключений?

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

Если религиозные воззрения не мешают, можно посмотреть на обработку exceptions в Win32. Согласна, не идеально - но вполне себе работоспособно.

Воззрения не мешают (считайте меня атеистом), только SEH в Windows — это далеко не то же самое, что exception в C++. И, если мне не изменяет память (последний раз под Windows я программировал лет 8 назад), try/catch С++ не ловит Win32 exceptions (я в курсе, что можно заставить MSVC ловить Win exceptions и преобразовывать их в C++ exceptions, но это не переносимо). Хотя лично я не против __try/__catch/__finally, при условиях а) поддержки компиляторами б) документированном и однозначном поведении при смешивании __try..__finally, __try...catch и try...catch.

> только SEH в Windows — это далеко не то же самое, что exception в C++

Но тем не менее, Вы согласны с тем, что было бы правильней, если бы try/cath ловил все исключения, а не только те что явно выкинуты из языковых конструкций, аналогично тому, как это происходит в JVM, когда NullPointerException явно не декларируется через throws, но может быть выброшен при соответствующих параметрах?

Полная переносимость «без ifdef» - миф, если же ifdef уже есть, какая нам разница - одним ifdef'ом больше, одним меньше - уже не важно. Но то, что исключения платформы сводятся к штатным std::exception, это очень даже хорошо, поскольку дает нам ту самую переносимость на уровне основной логики, которой Вы озаботились. Не надо заботиться о переносимости компиляторо-специфичного сервисного кода, лучше позаботиться о переносимости прикладного кода :-)

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

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

Ты уже второй раз в одном и том же топике морозишь какую-то феерическую фигню. ))) Давай, ты для начала научишься отделять линковку от компиляции. Я надеюсь, ты уже научилась отделять сигналы от исключений?

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

Поскольку я сам решаю, что мне делать, а что - нет, мне это не трудно. ))

придется делать транслирующий код

Ну вот, в третий. ((

Я понимаю, что ты поначиталась умных слов, но не надо комбинировать их в произвольном порядке. )) Осмысленных комбинаций очень не много, и комбинации «overcommit memory allocation» или «транслирующий код» в них не входят. ;)

можно посмотреть на

Можно, но не нужно. Добрый дядя sjinks расписал тебе уже _всё_ по полочкам. Должно дойти даже до самого тупого. Если до тебя по прежнему не доходит, просто уйди.

> SEH в Windows — это далеко не то же самое, что exception в C++

Угу, это совершенно ортогональная вещь.

> Пока что переносимая реализация выглядит как мичуринская колючая проволока

«Плохо ехать или хорошо стоять»?

> Поскольку , мне это не трудно

- А как вы обрабатываете исключения, порожденные ошибками работы чужого кода, возможно написанного на других языках и собранного другими компиляторами, которые могут возникнуть в любом вызове чужого кода?
- А я их никак не обрабатываю!
- ?!?!?!
- Я сам решаю, что мне делать, а что - нет!

Бесподобно :-)

> Пора вылезать из убежища 101, мир давно изменился - exception может быть выброшен в любой момент.

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

Можно пример действительно асинхронного исключения? И вообще как все это работает с деструкторами? и функциями со спецификатором throw который задает список возможных исключений?

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

int main()
{
//-> может возникнуть здесь
try
{
}
cath (...)
{
}
//-> может возникнуть здесь
return 0;
}

PS: Вообще сигналы лучше не мешать с исключениями а обробатывать их както иначе.

> Вообще сигналы лучше не мешать с исключениями а обробатывать их както иначе

Согласна, но увы - исторически так сложилось, что исключения и IPC были объединены в одну общую группу и названы «сигналами», а потом ради обратной совместимости они тянутся и тянутся дальше - собственно, в Java и .NET мы и видим нормальную концепцию, когда любое неправильное поведение ведет к порождению исключения, которое обрабатывается средствами языка. Ну а C++ (и особенно юниксовые реинкарнации его компиляторов) пытаются удержать совместимость с юниксовым же C. Вот и получается, что вместо того чтобы нормально ловить все исключения и отдавать их в try ... catch приходится растить кактусы.

И вообще если исключения будут асинхронными то я не смогу их отловить со сто процентной вероятностью

Ну на самом деле, ловить все исключения со 100% вероятностью вообще а) теоретически невозможно б) не особо и нужно большинству программ. Гарантированно ловить всяческие страшные SEGV, FPE и прочие нужно в очень небольшом проценте программ на сравнительно небольших участках. Лично мне довелось встречать (использовать, не писать) такие приложения раз пять, причем два раза это были VM и один раз СУБД :-)

>Ну на самом деле, ловить все исключения со 100% вероятностью вообще а) теоретически невозможно

Дайте пример кода где не возможно поймать исключение?

б) не особо и нужно большинству программ.

С вероятностью 100% ловить исключения, нужно всем нормальным программистам.

> Дайте пример кода где не возможно поймать исключение?

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

> Дайте пример кода где не возможно поймать исключение?

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

С вероятностью 100% ловить исключения, нужно всем нормальным программистам.

Пардон, оговорилась. Надо было сказать «проводить полностью корректную обработку исключений не особо и нужно большинству программ». Те же самые sigsegv, sigfault - если они случились, особо ничего не поделаешь, проще откоредампиться. А вот для какой-нибудь VM с JIT это уже далеко не всегда можно делать, что и видно на примере того самого кода из libjava, когда нужно обрабатывать сигнал как исключение.

> Но это опять к тому же, что исключения и сигналы лучше не мешать.

А как вы по другому в JVM с JIT будете FPE перехватывать? :-)

> А как вы по другому в JVM с JIT будете FPE перехватывать? :-)

А мы про какой ЯП сейчас говорим? Если что, я про C++.

Вопрос на засыпку: если обрабатывать сигнал на альтернативном стеке, реально ли из обработчика бросить исключение? И выполнится ли в этом случае stack unwind?

А как вы по другому в JVM с JIT будете FPE перехватывать? :-)

#define _GNU_SOURCE
#include <fenv.h>
#include <stdio.h>

int main(int argc, char** argv)
{
    fedisableexcept(FE_INVALID | FE_DIVBYZERO | FE_OVERFLOW | FE_UNDERFLOW);
    float a = 1., b = 0.;
    float c = a/b;
    printf("Got c\n");
    printf("c=%f\n", c);
    return 0;
}

Можно анализировать тип c (NaN, SNaN, QNaN, +INF, -INF...) и бросать исключение. Как один из вариантов.

PS: я не знаю, как это реализовано в java.

> > А как вы по другому в JVM с JIT будете FPE перехватывать? :-)

А мы про какой ЯП сейчас говорим? Если что, я про C++.

Я имела ввиду случай, когда Вы пишете свою VM с JIT. Хотя, этот пример как раз хорошо расширяется на любой случай, когда вы обрабатываете переданные пользователем данные - например табличный процессор также должен корректно обрабатывать overflow, а не падать по SIGFPE.

Вариант, пригодный для интерпретатора.

Проще маскировать исключения от FPU, а после выполнения вычислений проверять результат.

int raised;
feclearexcept(FE_ALL_EXCEPT);

double f = compute_something();

raised = fetestexcept(FE_ALL_EXCEPT );
if (raised & FE_OVERFLOW) throw EOverflow("...");
if (raised & FE_INVALID) throw EInvalid("...");
if (raised & FE_DIVBYZERO) throw EDivByZero("...");
/* ... */

Это будет переносимее, чем вся химия с кадрами стека, системными вызовами и шаманством вокруг знания того, как именно libc обрабатывает сигналы, ибо:

* http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1318.htm * https://www.securecoding.cert.org/confluence/display/seccode/VOID SIG36-C. Do... * https://www.securecoding.cert.org/confluence/display/seccode/SIG35-C. Do not ... * https://www.securecoding.cert.org/confluence/display/seccode/SIG32-C. Do not ...

Не только. Практический пример из мануала: http://www.gsp.com/cgi-bin/man.cgi?section=3&topic=fenv

Замените feraiseexcept на throw, добавьте fetestexcept() + if + throw в конце и будет счастье.

Насколько я понимаю, в этом коде вы плюете на факт наличия исключения и полагаетесь на то, что выполнение compute_something() успешно завершится и даст вам возможность проверить взведенные флаги после окончания расчета?

Это слегка некорректно, compute_something() далеко не всегда бывает вашим кодом, и нередко в алгоритмах результат выполнения используется в качестве исходных данных для следующей итерации, и существует достаточно заметная вероятность, что ваш код никогда не выйдет из функции - если, конечно вы не будете вставлять if (...) { throw ...; } в конце каждой итерации... Причем внутри compute_something, что вообще говоря может быть не всегда невозможно.

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

#define EVAL(x) x; if (fpe_failed) throw <what_you_want>
static int fpe_failed = 0;
void fpe_trap(int s) { fpe_failed = 1; }
int main() {
    signal(SIGFPE,fpe_trap);
    int i=1,j=0,k;
    EVAL(k=i/j);
}

> Насколько я понимаю, в этом коде вы плюете на факт наличия исключения и полагаетесь на то, что выполнение compute_something() успешно завершится и даст вам возможность проверить взведенные флаги после окончания расчета?

Нет. feclearexcept сбрасывает флаги исключения, оставленные с прошлых вычислений. В случае, если ранее был вызов к fedisableexcept, compute_something() не вызовет SIGFPE, соответственно, можно проверить флаги FPU на наличие исключений и бросить языковое исключение.

И еще я предполагал, что compute_something — моя функция (для случая с табличным процессором).

Хотя, ваш случай является частным случаем обработки SIGFPE

Нет. Если Вы сделаете возврат из обработчика SIGFPE, Вы рискуете попасть в вечный цикл. Сейчас даже пример подберу.

Обещанный контрпример:

#include <signal.h>
#include <stddef.h>
#include <stdlib.h>
#include <stdio.h>

volatile sig_atomic_t failure = 0;

void sighandle(int s)
{
        failure = 1;
        fprintf(stderr, "%s\n", "In SIGFPE handler");
        return;
}

int main(int argc, char** argv)
{
        int result = 0;

        if (argc < 2) {
                return 0;
        }

        int denom = (int)strtol(argv[1], (char**)NULL, 10);

        signal(SIGFPE,(*sighandle));

        result = 100/denom;

        printf("Result is %d\n", result);
        return 0;
}

gcc test.c -o test && ./test 0

и будет вечный цикл.

> Нет. Если Вы сделаете возврат из обработчика SIGFPE, Вы рискуете попасть в вечный цикл.

Ага, точно. Надо танцевать с контекстами и регистрами чтобы пережить выход из SIGFPE. Вы правы, слишком системозависсимо.

Нет. feclearexcept сбрасывает флаги исключения, оставленные с прошлых вычислений

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

И еще я предполагал, что compute_something — моя функция

Ну это как раз тривиальный случай, ибо со своей функцией можно делать что угодно :-)

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

Ну по крайней мере, SIGFPE там произойти не может, так как мы отключили генерацию исключений от FPU. Если нужно ловить языковые исключения, просто оборачиваем вызов в try...catch. Как-то так.

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

OOM-killer разве может генерировать сигнал отчличный от SIGKILL?

То что некоторые преобразованные сигналы в исключения нельзя поймать я и сам до этого показал. Я к тому что все эти хаки если они не могут гарантировать стандартное поведение то они не нужны. Преобразование сигнала SIGFPE, SIGPIPE в исключение может иметь место, так как места их возникновения четко определены и я их могу со 100% вероятностью поймать и обработать. А всякие асинхронные сигналы преобразовывать в исключения по моему это полный бред.

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

def term_handler
.....
end

install_term_handler(term_handler) // регистрируем обработчик сигнала

Ну или както иначе.

А кстати в java като обрабатываются асинхронные сигналы? Если да то где об это можно почитать?

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

Айлолд.

и собранного другими компиляторами,

Ну ты про линковку-то всё таки почитай )))

А то так и будешь талдычить как попугай про «другие языки и компиляторы». ))

> Ну по крайней мере, SIGFPE там произойти не может

Правда, потом автор «того» кода будет долго гадать, overflow, underflow или division by zero у него случился после вашего багрепорта :-)

> А кстати в java като обрабатываются асинхронные сигналы?

Асинхронные сигналы - низкоуровневое свойство платформы.

> Ну ты про линковку-то всё таки почитай

man dlopen почитайте

> А всякие асинхронные сигналы преобразовывать в исключения по моему это полный бред.

SIGTERM, когда программа находится в каком-нибудь ожидании?

При чем тут dlopen? Ты тычешь пальцем наугад в индекс манов?