Hi guys : I assumed that an integer overflow would through an exception, but I found otherwise (here are the factorials, computed using both recursion and a while loop, notice the negative numbers after )?
Im wondering : How does java deal with multiplication overflows ? I guess since its a primitive operation, there is no way to throw an exception....
But I have had NaN exceptions before, which I think are much cleaner.
jay vas wrote:Im wondering : How does java deal with multiplication overflows ? I guess since its a primitive operation, there is no way to throw an exception....
Java could have thrown an exception here - they just chose not to. They throw an exception if you divide by zero in integer division, for example. I think it was a bad decision not to throw an exception in the case of overflow, but they were probably trying to mimic existing behavior of c programs that people were used to back then.
jay vas wrote:But I have had NaN exceptions before, which I think are much cleaner.
They probably weren't NaN exceptions, but NaN results. These are possible values in floating-point operations, but not integer operations.
jay vas wrote:Any idea regarding the JVM specifics on this ?
Basically integer multiplication in java behaves as if the multiplication was done correctly, except that only the lowest 32 bits of the answer are retained. (Or 64 bits if any longs are involved.) No error or warning is given. It's very poor engineering, in my opinion.
On a daily base, making sure that my values don't overflow anywhere in my code gives me the biggest headache. Even if the language threw an exception in this case, it wouldn't change that you have to check everywhere whether there's a possibility for overflow. Still, using unchecked exceptions would have been much much better than silent overflow.
If your program theoretically uses infinite precision, you might want to consider using a BigInteger instead of regular ints or longs.
The mind is a strange and wonderful thing. I'm not sure that it will ever be able to figure itself out, everything else, maybe. From the atom to the universe, everything, except itself.
They shouldn't have thrown exceptions automatically, they should have gone the C# way - let the programmer decide to allow or deny overflow. By default integer overflow causes an exception (or error, can't remember) in C#, but with the addition of a keyword to the declaration of the variable it will overflow instead.
Another reason to permit overflow is to enable calculations of hash codes or similar, where one requires a result and doesn't care whether it overflows or not.
As Mike says, Java™ retains the rightmost 32 bits (or 64 for a long), so overflow is actually deterministic and predictable.
Joined: Oct 13, 2005
By the way: the overflow in those factorials occurs at no 13.
Joined: Mar 05, 2008
Rob Spoor wrote:They shouldn't have thrown exceptions automatically, they should have gone the C# way - let the programmer decide to allow or deny overflow.
100% agree, there are valid reasons to want to allow overflow, and sometimes you need it. As long as the default is to throw an exception. Or in some languages the default is to use an infinite-precision datatype - that can work well too.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com