Re: Problem with handling division by zero exception
On Fri, 07 Dec 2007 15:07:11 GMT, "a" <xxxxxxx@pacbell.net> wrote:
This may not be the right group, so if you know of a better one, please
direct me to it.
The code below (I'm showing just the relevant parts, no class definitions)
is intended to turn division by 0 (DBZ) structured exception into C++
exceptions, and it works almost well.
The way it works: first I call install which sets my_translator as the
structured exception handler, then when the DBZ happens, I re-throw it as a
C++ DivideByZeroExceptionImpl.
Note the calls to _controlfp in install to enable DBZ error in the FPU and
_clearfp to clear the exception after it was caught.
The only problem I have with this is that starting after the first 5 or so
such exceptions, after each C++ exception is caught, the first division
operation, no matter where in the code or what the operands, will result in
a NaN (Not a number) result. So to avoid this, I first perform a dummy
division then I continue the code normally. My understanding was that the
call to _clearfp would take care of any such problem.
All this is done using Visual Studio .Net 2003, and all the compiler options
that have to do with this are set properly (/EHa).
Any idea why this is happening and how to avoid it?
Sorry, no.
Related to this, I am puzzled by two other issues:
- why isn't it floating point DBZ exception enabled by default? IMO it is a
runtime error almost as serious as an access violation that must be handled
in most cases.
All floating point exceptions are masked by default, and unlike the case
with access violations, you can inspect the FPU status word at any time to
see if a floating point error has occurred at some point in the past. In
addition, floating point errors tend not to corrupt the overall state of
the program.
BTW, the correct "handling" of access violations in nearly all cases is to
do nothing, particularly not to interfere with the system. For more on
this, see:
http://members.cox.net/doug_web/eh.htm
- why isn't a std::runtime_error exception thrown in case of a DBZ error?
Can this be enabled?
No, it cannot be "enabled", except by using _set_se_translator. It isn't a
standard part of C++, because low-level errors such as this are handled in
various system-specific ways, to (loosely) quote Stroustrup (by distant
memory) in "The Design and Evolution and C++".
One problem with FP exceptions is that they are somewhat asynchronous. That
is, an FPU exception tends not to be raised until a subsequent FP
instruction is attempted. I concluded a long time ago that FP exceptions
are far more trouble than they're worth. It's almost always sufficient to
check the FPU status at the end of a calculation. Due to the asynchronous
nature of FP exceptions, you have to do this anyway (or something
equivalent) to ensure any pending FP exception will be raised.
--
Doug Harrison
Visual C++ MVP