Catch divide by zero

[Ian.W]

Question: How can I catch divide by zero situations (in debug, not release) without going in and adding an "if" before every division operation? (CVI 8.0.1)

Background: I recently learned I was benefitting from some of the sensible behavior of IEEE 754 floating points (see http://steve.hollasch.net/cgindex/coding/ieeefloat.html) For example take a look at the values b and c if you run this:

#include <utility.h>
#include <ansi_c.h>
main() {
 double a, b, c;
 a = 1. / 0.;               // +Inf
 b = exp(-(a * 0.));   //  NaN
 c = exp(-(a * 1.));   //  0.0
 Breakpoint(); }

In my case I was using a value like c and getting a sensible answer (0.0), but I'd rather catch any intermediate divide by zero situations while debugging.

Thanks,

Ian

[menchar]

Great question!

How do you catch a divide by zero exception (or any other math exception)?

I don't think it can be done in CVI, at least not when using the internal C compiler.

The C programming language provides the signal mechanism, and there's a signal for math exceptions. But signals don't work on Win32 OS's !  As far as the C language itself, in both C89 and C99 the consequences of divide by zero are undefined.

Even if you managed to raise the exception and invoke a handler, you can't throw an exception from one thread into another in Win32 !

As it turns out, the math processor in the x86 architecture "knows" about several different exceptions of various sorts, but getting to them is difficult, much less getting an exception raised.

A Visual C++ try/catch block should catch the divide by zero exception.  You have to use an "exception translator" to catch the Win32 exception and figure out which one it was - Win32 defines a EXCEPTION_FLT_DIVIDE_BY_ZERO and EXCEPTION_INT_DIVIDE_BY_ZERO, as well as a few other math exceptions.

Menchar

[AEDavidG]

Great answer, Menchar.  Thanks!

Also, please examine NI LabWindows/CVI Help -> Using LabWindows/CVI -> Debugging Tools for more options.

Cheers,
David Goldberg
Applications Engineer

[Ian.W]

Yes indeed, a great answer.  Thanks Menchar.

[menchar]

You're welcome.

Maybe we should try to get NI to put math exception support into their runtime engine, and provide a mechanism for applications to get a callback when one occurs in release mode code.

Your only real protection against divide by zero is to exert the discipline when coding to not allow it to happen.  I suspect there are a lot of apps out there that are vulnerable.  One device is to constrain numeric controls to not allow 0 as an input, or to check for it.

In general, you can really shoot your foot off in C, the paradigm is "trust the programmer".  If you can't be trusted to not do stupid things, then you should be using a different language.  I fight this battle all the time here at work with well-intentioned, intelligent people (systems guys typically) who aren't good C programmers and can't be trusted to do the right thing. So we spend a lot of time un-hosing improper pointer usage, callbacks 4000 lines in length, functions with 40 parameters, not using a distribution kit, etc. etc.  It's no mystery that modern languages generally disallow pointers (Ada, Java, C#).  In C++ you can blow off your whole leg.  Trying to mandate proper C coding practices usually fails - it becomes a game to try and bypass the constraints - and ignorant program managers reward shoot from the hip developers who appear to be coming up with quick results but in reality are hacking out code that is unstructured, error prone, fragile, and costs much more in the long term to supprt.

JPL is doing a thing where they require the developers to use maximum strength compiler error checking, and then a warning free analysis by a static code checker.  See "The Power of Ten" in a recent Computer magazine - ten rules to follow to get reliable code, some of which many veteran developers would object to.  But then, JPL's been burned big time by coding mistakes on deep space missions so they're sensitized to the issue 😉

Menchar