Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This happens in Javascript, for example, that division by zero is not handled by the language itself. Is there's a valid reason for this?

I see this as a very basic exception that a language should be able to handle (they even handle 0/0 as NaN NaN).

or take the square root of a negative number or use arithmetic operators with non-numeric operands that cannot be converted to numbers.

share|improve this question
1  
Well, different languages have different philosofies. Some might do what you are after. –  Job Aug 4 '11 at 2:44
5  
What is "not handled by the language" supposed to mean? The language spec defines that x/0 is [+-]Infinity and the language implementations include code for following that part of the spec. And the alternatives throwing an exception forces programmers to either watch their application crash, make sure the divisor is nonzero, or catch certain exceptions (not that the first two aren't options if division by zero instead returns a special value). And that's assuming the language in question has exceptions. –  delnan Aug 4 '11 at 6:02
add comment

3 Answers

up vote 6 down vote accepted

In my experience, these sort of things rarely come about ue to any sort of technical limitation but more due to architectural beliefs / ideas of the language designers.

Yes the language could handle division by zero... but maybe they thought it would be 'better' if the language didn't and developers were forced to explicitly define what should happen in such a scenario.

In a similar fashion, Objective-C 'handles' attempting to call a non-existant object with no complaint or warning yet a lot of C# developers frown on this as a possible language feature.

It's all about where you're standing and what you're trying to achieve.

share|improve this answer
    
There's a common philosophy of failing early, and throwing an exception is a fair example of that. If you return special values instead, that means you have special cases to test for later in your code - probably over and over again. If you have multiple calculations that may return special-case results, you have a combinatorial explosion of special cases to deal with over-and-over later in your code. For trivial programs this isn't a big deal, but larger programs rapidly get unmanageable. –  Steve314 Aug 5 '11 at 1:08
    
@Steve314: Unless a language is going to have distinct numerical types or operators for trapped and untrapped arithmetic, it's generally more useful to have floating-point operations other than "checked" methods for I/O or conversion to integers be untrapped, and check values for validity at the end of calculation. –  supercat Mar 12 at 6:42
    
@supercat - maybe you're referring to something like NaN which (in effect) is an error value defined as part of IEEE754 - so that IEEE754 floats are similar, in a way, to a Haskell Maybe type. I would say that is a kind of checked operation and arguably a kind of exception handling that propagates through expressions (rather than calls), though of course the "did an error occur" check must be done explicitly somewhere. The downside of this approach is that, after the NaN result has propagated out through many layers of calculations, it's hard to trace the original cause. –  Steve314 Mar 12 at 11:12
    
@Steve314: I was indeed referring to NaN; since the whole purpose of most floating-point calculations is to end up with something other than a floating-point number (generally either an integer or a string), ensuring that the methods which convert floating-point values to something else do not produce a result that might be mistaken for that of a valid number, NaN values are going to get detected or trapped someplace. BTW, I recall that Turbo Pascal supported a 64-bit signed integer type which had a NaN of 0x8000000000000000. Such a concept would seem helpful... –  supercat Mar 12 at 15:39
    
...if it were available with other types, though absent hardware support it would probably be too expensive to emulate in software. –  supercat Mar 12 at 15:43
add comment

JavaScript is actually a good candidate for that kind of behavior because it runs code from an unknown/untrusted source. Allowing unsupervised divides would enable code in web pages to force the interpreter to divide by zero, causing the CPU to raise an interrupt that will in turn cause the OS to torpedo the interpreter's process. If the browser running the interpreter doesn't sequester the interpreter in its own process, it's going to be sunk as well.

I think in this case it falls under the heading of maintaining stability at the expense of the programmer having to understand that doing an illegal operation will result in a wrong answer instead of having the whole thing go kablooey.

share|improve this answer
add comment

The problem is deciding what the correct result is. Who else but the programmer can make that decision. The language designer or compiler writer cannot.

e.g.

int32 x= 0/0 ; 
int32 x= 1/0 ; 

Is it 0 or NaN or Infinity respectively - if NaN or Infinity, how do you represent it, its' 32 bit binary number?

share|improve this answer
3  
The correct result is NaN, because division by zero is not permitted. There's no decision making involved in this. –  blubb Aug 4 '11 at 10:42
    
Infinity is NaN (not a number) –  Tom Squires Aug 4 '11 at 13:07
    
Thanks for pointing out the obvious. I have fixed the post. –  mattnz Aug 4 '11 at 20:48
    
@Tom Squires: They are not equal. Infinity is a number larger than any other number you can describe, while NaN is a placeholder value denoting the absence of an actual value. –  blubb Aug 4 '11 at 21:00
    
@Simon - what about 0/0, which can arguably have any value as it's result? It's still not a (single) number, but maybe a different special-case value? Which special-case values you use can depend on a range of details - the floating point standard had a lot of past experience to base things like that on. In programming, you can't state that the set of integers is just a restricted subset of the set of rationals - the ways integer types are used in programming are different. –  Steve314 Aug 5 '11 at 1:14
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.