Who hasn't created a program, process, routine, or function which has resulted in a DIVIDE BY ZERO error? It has always puzzled me why any proposition which results in the division of a finite number by zero is not handled by the programming language (compiler/interpreter) such as to return a result, rather than allowing an attempt at a solution and thereby bomb. The mere addition of representation character(s) for INFINITE, or UNDEFINED might make an algorithm in which a proposition might contain a division by zero return the representation character(s) instead of bombing out. I know that special error-code handling via exceptions can be supplied by the programmer, but I am here suggesting provisions made in the language itself to handle propositions which result in "failure to compute", and as a result termination or other undesirable processes. This could prove to be useful in the construction of algorithms. [I'm afraid I don't see how this would prove useful. Do you have any examples?] Think about it for a while. Wouldn't it be better if the returnedValue from an evaluated numeric expression would always return one of the following results: Value of 0, NONZERO FINITE value, INFINITE, UNDEFINED, TRUE or FALSE? ''I don't think that claim could be justified. It would be better if the numeric expression always failed in a predictable manner that allowed for proper handling (error-codes and exceptions apply; automatic 'termination or other undesirable processes' do not), but I'd choose exceptions over use of error codes. There is no particular reason that the language itself, rather than just programmers, couldn't supply the exceptions.'' I am not talking about failing, ''exceptions, error codes, or special handlers.'' I am saying that when an numeric expression is evaluated, that the language itself provides failure transparency in that it would return either a numeric return value, a boolean, or a type called INFINITE. That makes three ''predictable'' outcomes. ''I'm firmly of the opinion that ''failure'' is a condition that should never be transparent. And while I don't want a definition battle at the moment, I do consider returning NONZERO FINITE, INFINITE, UNDEFINED, etc. to be error codes, as they are errors encoded into the return value. There is precedent for calling such error codes, e.g. returning various negative numbers for errors when the 'real' answer would always be positive.'' [I still don't see how this is useful. How is adding additional special cases going to make the one special case better? I can't think of anything this would simplify/improve, while I can think of any number of problems with it. (E.g. You'd have to check for one of those special cases when evaluating a loop's conditional or risk being stuck in the loop forever.)] If a divide by zero error occurs in a for loop under normal programming procedures, what happens? ''That depends on the language in use. Some go down hard. Others throw an exception. Others have a (global) callback handler from the OperatingSystem. I prefer use of the exception.'' ---- Failing to see how it would be useful, you could provide your own handler for divide by zero errors in the language of your choice. Some might see the usefulness of such a provision in a language which would employ the technique and avail themselves of it. [I prefer to not divide by zero with exceptions as a back up.] ---- Isn't DIVIDE BY ZERO error a kind of MuAnswer... What is the right representation of a MuAnswer? adding the representation character(s) for Mu? (Null? Infinite? Undefined?) or plain throwing an exception?) ''Throwing an exception or returning a special error-code are both fine 'MuAnswer''''''s'. Segmentation faults, crashing, performing 'undefined' operations, and entering infinite loops are not very good MuAnswer''''''s. 'Infinite' would only be a reasonable error if you divided by an infinitesimal (+0.0,-0.0) that were considered to be 'not zero but arbitrarily close', but such hacking of basic floating point representations is questionable at best; one would be better served by adding a math-library supporting calculus and asymptotic functions.'' Ste FloatingPoint standard IEEE754 defines NaN and others as results of low level arithmetic on floats. Throwing an exception is but one means of dealing with these values. ---- Related: * IeeeSevenFiftyFour * Floating Point Numbers -- http://hal.archives-ouvertes.fr/docs/00/18/22/52/PDF/floating-point-article.pdf ---- CategoryAlgorithm