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.
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.
posted 9 years ago
By the way: the overflow in those factorials occurs at no 13.
posted 9 years ago
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.
Catching Integer Overflows is nice to have but there is a large performance overhead. Each time a calculation is done a comparison has to made which is not affordable in real world applications. This is a typical tradeoff between performance and correctness for which each PL has to decide.
posted 1 year ago
Welcome to the Ranch
You have a good point there, and it is never really too late to reply. To come back to Rob S's point: that post was before the introduction of this sort of method. Note the link says, “Since 1.8.”
There are 29 Knuts in one Sickle, and 17 Sickles make up a Galleon. 42 tiny ads in a knut: