Why do int and decimal throw a DivideByZeroException but no floating point?

Question

According to http://msdn.microsoft.com/en-us/library/system.dividebyzeroexception.aspx only Int and Decimal will throw a DivideByZeroException exception when you divide them by 0, but when you divide the floating point number by 0, the result there will be infinity, negative infinity or NaN. Why is this? And what are some examples where the result is + ve infinity, is infinity or NaN?

Answer 1

The IEEE Standards Committee considered that exception handling was more of a problem than it cost for a range of code that could meet these problems with floating point math

Traps can be used to stop a program, but fatal situations are extremely rare.
[...]
Flags offer both predictable control flow and speed. Their use requires the programmer to be aware of exceptional conditions, but the stickiness flag allows programmers to defer processing of exceptional conditions until necessary.

This may seem strange to a developer accustomed to a language in which exception handling is deeply baked, such as C #. Developers of the IEEE 754 standard are thinking of a wider range of implementations (for example, embedded systems) where such tools are not available or undesirable.

Answer 2

Michael's answer, of course, is correct. Here is another way to look at it.

Integers are exact. When you divide seven by three in integers, you really ask the question "how many times can I subtract three from seven before I have to go to negative numbers?". Division by zero is undefined because there are no number of outputs, you can subtract zero from seven to get something negative.

Floats are inherently inaccurate. They have a certain degree of accuracy, and you'd better assume that the “real” amount is somewhere between the given float and the float next to it. Moreover, floats are usually physical quantities, and they have a measurement error much larger than a representation error. I think of the float as a fuzzy blurry area surrounding a point.

So, when you divide seven by zero in the floats, think of it as dividing a certain number close enough to seven by a certain number close enough to zero. Obviously, a number close enough to zero can make the factor arbitrarily large! And so this is signaled to you, giving infinity as an answer; this means that the answer can be arbitrarily large, depending on where the true value is actually located.

Answer 3

The floating-point engine built into the processor is quite capable of throwing exceptions for float division by zero. Windows has an exception code allocated for it, STATUS_FLOAT_DIVIDE_BY_ZERO, exception code 0xC000008E, "Floating point division by zero." Like other failures that the FPU can report, such as overflow, underflow, and inaccurate results (aka denormals).

Whether this is determined by this control register, programs can change this register using an auxiliary function such as _ controlfp () . Libraries created using Borland tools typically did this, for example by exposing these exceptions.

That didn't work, to say the least. This is the worst possible global variable you can imagine. Mixing such libraries with others that are expecting division by zero to generate infinity instead of an exception simply does not work and is almost impossible to process.

Accordingly, currently the norm for language loops is to mask all floating point exceptions. The CLR insist on this as well.

Working with a library that masks exceptions is complicated, but has a stupid workaround. You can throw an exception and catch it again. The exception handling code inside the CLR resets the control register. An example of this is shown in this answer .