Re: Handling Floating Point Exception in VC++ 6.0
Thanks for all the replies.
I did some more reading and I think I am more confused than before.
I decided to upgrade and use VC++ 2005 rather than VC++ 6.0
I read the following article
http://www.devx.com/cplus/Article/34993/1954?pf=true
my compiler options are
/EHa
/fp:precise
/fp:except
/Od
My basic question is
What is the best way to handle math exceptions?
Currently the code I wrote does not bomb out when there are division by
zeros, but a NaN type of value is returned. I would like to be able to
handle exceptions so I can log the error and assign appropriate values.
Two ways I considered are
1) Write my own divide class where I check for the denominator if it is
zero and then throw an exception.
CONS: It may affect the performance of my code since I am doing all those
check
Code may become unreadable
Not sure how to check for things like OVERFLOW and UNDERFLOW before the
calculations take place
2) Enable floating point exception, I used the code that was in the article
I linked to, but I was not able to get it to work. The catch(...) catches
the exception but when I read the status word, it does not give me the
correct value for OVERFLOW, it has a value of 0. When I do log(-1) it gives
me a value of 0.
Below is the code I used
/Set the x86 floating-point control word according to what
//exceptions you want to trap.
_clearfp(); //Always call _clearfp before setting the control
//word
//Because the second parameter in the following call is 0, it
//only returns the floating-point control word
unsigned int cw = _controlfp(0, 0); //Get the default control
//word
//Set the exception masks off for exceptions that you want to
//trap. When a mask bit is set, the corresponding floating-point
//exception is //blocked from being generating.
cw &=~(EM_OVERFLOW|EM_UNDERFLOW|EM_ZERODIVIDE|
EM_DENORMAL|EM_INVALID);
//For any bit in the second parameter (mask) that is 1, the
//corresponding bit in the first parameter is used to update
//the control word.
unsigned int cwOriginal = _controlfp(cw, MCW_EM); //Set it.
//MCW_EM is defined in float.h.
//Restore the original value when done:
//_controlfp(cwOriginal, MCW_EM);
it looks like from the article that i should not be using catch(...)
try
{
double numerator = -1.0
double A = log(numerator);
}
catch(...)
{
int fpStatusWord = _clearfp();
switch(fpStatusWord)
{
case _EM_INEXACT:
break;
case _EM_ZERODIVIDE:
break;
case _EM_UNDERFLOW:
break;
case _EM_OVERFLOW:
break;
case _EM_INVALID:
break;
default:
break;
}
any help is greatly appreciated.
"Doug Harrison [MVP]" wrote:
On Wed, 3 Dec 2008 14:45:05 -0800, SONET <SONET@discussions.microsoft.com>
wrote:
I've been trying to handle floating point exceptions but I am having some
problems.
Basically I am able to catch the exception with the catch(...), I wrote a
class that should be thrown but it is not working.
I basically coded the following class
FloatException::FloatException( int nSubCode )
{
subCode = nSubCode;
_fpreset();
}
void FloatException::FloatExceptionHandler( int sig, int nSubCode )
{
throw( new FloatException( nSubCode ) );
}
void FloatException::SetFloatExceptionHandler()
{
// Get the current floating point control word.
//unsigned int uWord = _controlfp( 0, 0 );
unsigned int uWord = 0;
// Set the exceptions we want
uWord |= _EM_UNDERFLOW;
uWord |= _EM_OVERFLOW;
uWord |= _EM_ZERODIVIDE;
uWord |= _EM_INVALID;
_controlfp(uWord, _MCW_EM);
uWord = _controlfp( 0, 0 );
// Set the exception handler.
signal( SIGFPE, (void (__cdecl*)(int))FloatExceptionHandler );
}
in the main code I do this
FloatException::SetFloatExceptionHandler();
try
{
double temp = exp(99999999);
}
catch(FloatException& e)
{
}
catch(...)
{
}
the problem is that it never hits the FloatException catch, and it never
executes the FloatExceptionHandler. it does get caught in the catch(...)
which didn't do before I wrote the code.
Is there something I am missing? Is there a better way to do floating point
exception.
Get rid of the signal call and use _set_se_translator. It looks like your
signal handler is never being called, and you're catching a Windows
structured exception in catch(...). For reasons why that is bad, see:
http://members.cox.net/doug_web/eh.htm
Note that it's no longer done under /EHs in recent versions of VC, and you
can download the Express Edition here:
http://www.microsoft.com/express/vc/
In order to use _set_se_translator, you also have to use /EHa, which brings
back the catch(...) ability to catch SEs, including untranslated, raw SEs,
so it remains not the greatest thing in the world. Have you considered
/not/ enabling FP exceptions? There are a couple of things to consider
besides the /EHa requirement, (1) They are not raised until a subsequent
FPU instruction is attempted, which means you need to do an _fwait or
equivalent at the end of a calculation, and (2) They are cumulative, which
means if you leave FP exceptions masked (disabled), you can poll the status
word with _statusfp at the end of a calculation and detect any error that
would have manifested in an exception had exceptions been enabled. Provided
there are natural places to call _statusfp, that's what I would use.
I am running Windows XP on a Xeon. Does the processor matter?
AFAIK, no.
--
Doug Harrison
Visual C++ MVP