Xojo divides by ZERO?

I was expecting an Exception, but got a negative value

Var x,y As Integer
x = x / y
Break           // 0 / 0? No problem! That's -2147483648

Xojo 2021 R3.1

1 Like

i got the same result at x86 32bit.

at 64bit i get 0 without error

I don’t think it’s ever raised an Exception. While I agree it should, I’m not sure it’s a good idea to change it now.

If you cast to a double, you get NaN, at least.

@Kem_Tekinay

Yes

Xojo is not a language that has ever raised an exception for divide by 0. Docs say:

If you divide by zero, the result is positive or negative infinity, except if the numerator is also zero. In that case, the result is NaN. For that reason, you should always check to see whether the denominator is zero before using / .

2 Likes

Imagine how silent huge errors could rise doing math and getting a huge and acceptable unexpected negative number. That’s not a NaN, nor Infinity. And The behavior is inconsistent as pointed by Markus, for 32 bit, -2147483648, for 64 bit, ZERO (that I think that potentially could cause less damages as an expected silent wrong result).

Yes, we should check everything, and that’s how I raised this topic, but in case of someone not doing it, there’s worst and better outcomes, and accepting silently 0 / 0 = -2147483648 seems to fit in my list of worst cases. The behavior must be documented, and should be consistent throughout the platforms.

Integer math in other languages raises Divide by Zero exceptions, just floating math not, they return special values for some invalid operations, as NaN and Infinity.

2 Likes

Ideal coding practice would be to check if the divisor is zero before performing the division.

Everyone usually does it. That’s not the question here. The question here is the unusual behavior adopted for an integer divide by zero ending in inconsistent and dangerous silent values.

Try that in another language, i.e. C# (DivideByZeroException), Java ( ArithmeticException), Python ( ZeroDivisionError), etc

What if users from other languages expected such behavior and enclosed an int expression in a try catch block instead of ifs? With that huge negative number as result, a catastrophe.

I learned early when doing statistics programming in FORTRAN not to trust that a variable had an actual value.

If I do recall correctly (the last time I touched FORTRAN it was almost 40 years ago), FORTRAN would stop the calculation, and print an error message if finding such condition. We hadn’t Try/Catch, Exceptions, Traits, all this modern stuff we have today. Even with FORTRAN we couldn’t get 0/0 = -2147483648 in those ancient times.

I agree that an exception for divide by zero is preferred. Regarding Xojo, these decisions were made 20+ years ago.

I’m not sure if changing this behavior after such a long time is a good idea, but it is worthy of discussion. I didn’t notice a Feedback case for this, which I think would be worthwhile.

This seems like a bug on Windows and Linux. I get the expected large negative value on macOS. This would also be worth a Feedback case.

2 Likes

As languages evolves, bad decisions are reviewed, modernizations are made, things are phased out, functions deprecated, corrections are made.

Sad.

If I could, I would lock this thread.

I agree.

Since you’d rather do out-of-context quoting instead of continuing a reasoned discussion, this topic is now locked.