Maneesh Godbole wrote:I think it's because thats a runtime evaluation and as such the onus is on the developer, just like null pointers.
I'm not sure this explanation is logical. At run time if one tries to de-reference a null pointer a NullPointerException is thrown but if one performs a divide by zero then no exception is thrown!
I do a lot of work with doubles and every now and again I would like to be able to indicate to the JRE that a particular double operation may produce a NEGATIVE_INFINITY or POSITIVE_INFINITY and I would like to be informed of the fact without me having to check. One of the advantages of throwing exceptions is that code is not littered with the operation validity checks that characterize other languages such as C.
This is not a Java specific behavior, as divide by zero behavior is specified by the IEEE 754 specification.... A positive number that is divided by positive zero must result in positive infinity.
Henry Wong wrote:
A positive number that is divided by positive zero must result in positive infinity.
I know why they do it like that, but that sort of description does make the mathematician in me cry a little .
Matthew Brown wrote:I know why they do it like that, but that sort of description does make the mathematician in me cry a little .
Well...since the mathematicians chose not to define "divide by zero", the CS folks had to pick up the slack.
Campbell Ritchie wrote:0.0 is one of the numbers you can be absolutely sure a double represents accurately and precisely!
Well, it depends which way you're going. If you know that 0 is what you're trying to represent, then 0.0 is guaranteed to represent it accurately as a double However if you get a 0.0 result, you don't know for sure that it should really represent 0. It might also "really" be a number very close to 0 that got rounded off to 0.0.