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.
As RT has hinted, the reason is to do with the range of the values. A double supports ±∞ values, so it can be divided by 0. If you try dividing an integer primitive by 0.0, which is a double, you promote that integer to a double, again getting ±∞. More strangely still, a double supports “NaN” values, too. You should be able to find how those values are defined here, remembering that 0.0, 0d and 0D are all ways you can write a double literal for 0 in Java.
posted 6 years ago
And if it takes you > 5 seconds to think of a more efficient version of that method, I shall be very surprised!
I'm not sure, but I would guess that the reason is that, due to the inherent imprecision in FP numbers, when you divide by 0.0, it might be that the actual value isn't 0.0, but that's the closest double could come to representing the true value. So rather than throw an exception, it says, "You're dividing by a really tiny number, tinier than I can represent, so the result is going to be bigger than I can represent, so here's my catch-all really big value."
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.
posted 6 years ago
I see what you mean. I meant if you write 0.0 as a literal.