Здравствуйте все!
Такая ситуация интересная:
Visual Stidio 2008.
Есть код типа этого:

int V = 0;
double d,Old = 0.0;
try {
  d = (double)V/Old;
} catch (...) {
 PRINT_LOG();
}
a = d;

catch(...) отрабатывает, НО:
после него не выполняется a = d, а исключение вылетает выше — в вызвавшую ф-ию, где тоже есть try-catch. Отрабатывает следующий catch(...) и после него — тоже вылетает на уровень выше и программа выполняет недопустимую операцию.
SEH включена (/EHa).
Исключения для Floating point включены (/fp:except).

В вывод пишет такое:

Первый этап обработки исключения в "0x00c67b5c" в "Project1.exe": 0xC0000090: Floating-point invalid operation.
Первый этап обработки исключения в "0x00c5d5a8" в "Project1.exe": 0xC0000090: Floating-point invalid operation.
Первый этап обработки исключения в "0x727b23cc" в "Project1.exe": 0xC0000090: Floating-point invalid operation.
Первый этап обработки исключения в "0x75ea7c1a" в "Project1.exe": 0xC0000090: Floating-point invalid operation.
Первый этап обработки исключения в "0x727b23cc" в "Project1.exe": 0xC0000090: Floating-point invalid operation.
Первый этап обработки исключения в "0x75ea7c1a" в "Project1.exe": 0xC0000090: Floating-point invalid operation.
Первый этап обработки исключения в "0x75ea7c1a" в "Project1.exe": 0xC0000090: Floating-point invalid operation.
Первый этап обработки исключения в "0x727b23cc" в "Project1.exe": 0xC0000090: Floating-point invalid operation.
Первый этап обработки исключения в "0x727b23cc" в "Project1.exe": 0xC0000090: Floating-point invalid operation.
Первый этап обработки исключения в "0x00c66f54" в "Project1.exe": 0xC0000090: Floating-point invalid operation.
Первый этап обработки исключения в "0x6d6466f6" в "Project1.exe": 0xC0000090: Floating-point invalid operation.
Первый этап обработки исключения в "0x75ea7c1a" в "Project1.exe": 0xC0000090: Floating-point invalid operation.
Первый этап обработки исключения в "0x75ea7c1a" в "Project1.exe": 0xC0000090: Floating-point invalid operation.
Первый этап обработки исключения в "0x75ea7c1a" в "Project1.exe": 0xC0000090: Floating-point invalid operation.
Первый этап обработки исключения в "0x75ea7c1a" в "Project1.exe": 0xC0000090: Floating-point invalid operation.
Необработанное исключение в "0x75ea7c1a" в "Project1.exe": 0xC0000090: Floating-point invalid operation.

Как это вообще получается? Что я не так делаю?
Почему catch'и получают управление, но исключение продолжает передаваться выше?
Как бороться?
(__except пока не пробовал — не дает использовать из-за объектов, да и с catch бы разобраться...)

Заранее всем спасибо.

Здравствуйте, al777, Вы писали:

A>Есть код типа этого:

A>

A>int V = 0;
A>double d,Old = 0.0;
A>try {
A>  d = (double)V/Old;
A>} catch (...) {
A> PRINT_LOG();
A>}
A>a = d;
A>

вы что-то путаете, нигде c++ исключения у вас в коде генерироваться не могут, поэтому и поймать то, что не генерируется- тоже неполучится.

S>вы что-то путаете, нигде c++ исключения у вас в коде генерироваться не могут, поэтому и поймать то, что не генерируется- тоже неполучится.

Я думал /EHa позволяет отлавливать все исключения... Разве не так?
И как тогда отловить "Floating-point invalid operation"?

Здравствуйте, al777, Вы писали:

A>catch(...) отрабатывает, НО:
A>после него не выполняется a = d, а исключение вылетает выше — в вызвавшую ф-ию, где тоже есть try-catch. Отрабатывает следующий catch(...) и после него — тоже вылетает на уровень выше и программа выполняет недопустимую операцию.

видимо не скинулись флаги "сопроцессора". Я их руками всегда скидываю, но у нас немного другая ситуация, мы сами и перехватываем.

Здравствуйте, al777, Вы писали:

A>Как бороться?
A>(__except пока не пробовал — не дает использовать из-за объектов, да и с catch бы разобраться...)
покури _set_se_translator

Здравствуйте, al777, Вы писали:

S>>вы что-то путаете, нигде c++ исключения у вас в коде генерироваться не могут, поэтому и поймать то, что не генерируется- тоже неполучится.

A>Я думал /EHa позволяет отлавливать все исключения... Разве не так?
A>И как тогда отловить "Floating-point invalid operation"?
Это не обрабатывается стандартными операторами С++, а расширениями Студии.
try+except и try+finally
Подробно описано у Рихтера.

Здравствуйте, LaptevVV, Вы писали:
LVV>Это не обрабатывается стандартными операторами С++, а расширениями Студии.
LVV>try+except и try+finally
LVV>Подробно описано у Рихтера.

Наверное, так и есть, но почему catch(...) срабатывает!?
(Понимаю что вопрос дурацкий...)

Здравствуйте, al777, Вы писали:

A>Здравствуйте, LaptevVV, Вы писали:
LVV>>Это не обрабатывается стандартными операторами С++, а расширениями Студии.
LVV>>try+except и try+finally
LVV>>Подробно описано у Рихтера.

A>Наверное, так и есть, но почему catch(...) срабатывает!?
A>(Понимаю что вопрос дурацкий...)
1. В 10-й студии сделал такой пример:

#include <iostream>

int main()
{
    try{ int a = 1, b = 0;
    b = a/b;
    }
    catch(...)
    {
        std::cout << "Yes!" << std::endl;
    }
    system("pause");
    return 0;
}

В дебаге, естественно ловится деление на ноль. Но не catch-ем, а отладчиком — деление на ноль.
В релизе при запуске в среде в режиме без отладки вообще ничего не ловится.
Еще проставьте запрет расширений С++ в студии.

Здравствуйте, Caracrist, Вы писали:

C>Здравствуйте, al777, Вы писали:

A>>Как бороться?
A>>(__except пока не пробовал — не дает использовать из-за объектов, да и с catch бы разобраться...)
C>покури _set_se_translator
Спасибо, я даже не знал о такой.

Здравствуйте, Ops, Вы писали:

Ops>Здравствуйте, Caracrist, Вы писали:

C>>Здравствуйте, al777, Вы писали:

A>>>Как бороться?
A>>>(__except пока не пробовал — не дает использовать из-за объектов, да и с catch бы разобраться...)
C>>покури _set_se_translator
Ops>Спасибо, я даже не знал о такой.

Стек не размотается, будьте бдительны...

Здравствуйте, meerius, Вы писали:

M>Здравствуйте, Ops, Вы писали:

Ops>>Здравствуйте, Caracrist, Вы писали:

C>>>Здравствуйте, al777, Вы писали:

A>>>>Как бороться?
A>>>>(__except пока не пробовал — не дает использовать из-за объектов, да и с catch бы разобраться...)
C>>>покури _set_se_translator
Ops>>Спасибо, я даже не знал о такой.

M>Стек не размотается, будьте бдительны...

Т.е. не размотается? Я так понял, что structured/vectored исключение сразу транслируется в C++ исключение, а дальше все и так понятно. Естественно, если использовать /EHa, но в описании и так об этом явно сказано. Или я не прав?

Вот слегка модифицированный код из примера MSDN:

#include <stdio.h>
#include <windows.h>
#include <eh.h>

void SEFunc();
void trans_func( unsigned int, EXCEPTION_POINTERS* );

class A
{
public:
    A(){printf( "ctor A\n" );}
    ~A(){printf( "dtor A\n");}

};

class SE_Exception
{
private:
    unsigned int nSE;
public:
    SE_Exception() {}
    SE_Exception( unsigned int n ) : nSE( n ) {}
    ~SE_Exception() {}
    unsigned int getSeNumber() { return nSE; }
};
int main( void )
{
    try
    {
        _set_se_translator( trans_func );
        SEFunc();
    }
    catch( SE_Exception e )
    {
        printf( "Caught a __try exception with SE_Exception.\n" );
    }
}
void SEFunc()
{
    A a;
        int x, y=0;
        x = 5 / y;
}
void trans_func( unsigned int u, EXCEPTION_POINTERS* pExp )
{
    printf( "In trans_func.\n" );
    throw SE_Exception();
}

Вывод, как и ожидалось:

ctor A
In trans_func.
dtor A
Caught a __try exception with SE_Exception.

Так что стек нормально разматывается.

Здравствуйте, al777, Вы писали:

A>Здравствуйте все!
A>Такая ситуация интересная:
A>Visual Stidio 2008.
A>Есть код типа этого:

A>

A>int V = 0;
A>double d,Old = 0.0;
A>try {
A>  d = (double)V/Old;
A>} catch (...) {
  _clearfp();
A> PRINT_LOG();
A>}
A>a = d;
A>

A>Как это вообще получается? Что я не так делаю?
A>Почему catch'и получают управление, но исключение продолжает передаваться выше?
При делении на ноль и тому подобному устанавливается соответствующий статус, т.к. он не сбрасывается исключения будут кидаться снова и снова.

A>Как бороться?

_clearfp в catch спасёт отца русской демократии.

A>(__except пока не пробовал — не дает использовать из-за объектов, да и с catch бы разобраться...)

И не надо, с catch тоже будет работать.

Поигрался я, поигрался...
Пробовал _set_se_translator() (спасибо Caracrist) — та же фигня происходит, но вещь сама по себе полезная.
На всякий случай отмечу, что [как я понял] /fp:except в моем случае ни на что не влияет, а SEH-исключения нормально обрабатываются catch(...) при включении /EHa.
Полечилось только с помощью _clearfp() — похоже, не сбрасывался флаг исключения какой-нибудь (опять таки — почему?), и после catch(...) любое обращение к сопроцессору приводило к еще одному исключению и так далее.
В общем, всем большое спасибо!
Отдельная благодарность k.o. и Сергею Мухину!

Здравствуйте, Caracrist, Вы писали:

A>>(__except пока не пробовал — не дает использовать из-за объектов, да и с catch бы разобраться...)
C>покури _set_se_translator

и причём тут с++ ?

Здравствуйте, Sni4ok, Вы писали:

S>Здравствуйте, Caracrist, Вы писали:

A>>>(__except пока не пробовал — не дает использовать из-за объектов, да и с catch бы разобраться...)
C>>покури _set_se_translator

S>и причём тут с++ ?
при том, что все подобные исключения платформозависимы, а это один из частных случаев, позволяющих обработать их в C++.

Здравствуйте, Ops, Вы писали:

S>>и причём тут с++ ?
Ops>при том, что все подобные исключения платформозависимы, а это один из частных случаев, позволяющих обработать их в C++.

так в с++ или в неком расширении некого компилятора?

Здравствуйте, Sni4ok, Вы писали:

S>так в с++ или в неком расширении некого компилятора?
вопрос находится в "Прикладных вопросах" и ТС сразу обозначил компилятор (VS2008) и некие флаги компиляции, поэтому демагогия на тему "true C++" тут, очевидно, является офтопиком