I think you’re saying that any attempted conversation of INF or NAN to integer should raise an exception, and I agree. There is simply no non-arbitrary way to represent those values as integer, and any code that is doing that silently is just masking a bug.
3 Likes
Yes, unless you have some pragma to disable such check and know what you’re doing.
2 Likes
Until now, I firmly believed that Xojo would throw an exception when dividing by zero.
I hope this will be changed, even if it might jeopardize some of the code that currently works.
1 Like
I hope it stays as it is. The behavior is clearly documented and there is an obvious way to deal with it (using the IsNotANumber and IsInfinite methods), so there is really no problem that would require solving.
Criticize me if you wish but I even use a NaN value to indicate that some Double value is unknown: I divide by 0, store the result, and assign that whenever a value is unknown.
2 Likes
Xojo aims to be an easy-to-use alternative to other basic variants, especially for beginners. And I suspect there are quite a few beginners who use algorithms that can involve division by zero. If an undefined value is actually returned instead of an error, this erroneous output from the algorithm may be processed further. Unbeknownst to the code author, the results may be incorrect.
Xojo’s current behavior isn’t wrong. However, I personally would prefer an exception error at this point. 
To keep the current behavior, but also enabling a proper check, a #Pragma should exist, as
#Pragma DivideByZeroError Default True // Sets current default
#Pragma DivideByZeroError Default False // System Default
#Pragma DivideByZeroError True // Change just the current method from here to its end
#Pragma DivideByZeroError False // Change just the current method from here to its end
So at App.Opening() you could put a #Pragma DivideByZeroError Default True
Putting a #Pragma Default in any place not except App.Opening() should lead to an error like “Defaults must be set as the first instructions. Try at App.Opening()”
It should affect just the current App being built, any pre-compiled content, as a plugin, should obey what was set there when it was compiled.
Thankfully any further calculations involving a NaN, INF, or -INF will result in another NaN, INF, or -INF value so the result will not be incorrect – just not a meaningful number.
I had only checked Doubles operations where it appears to be true. Your examples involve conversions from Double to Integer and apparently NaN, INF, and -INF don’t get converted properly.
Because it’s impossible. That’s why exceptions arises when risk math operations occurs as DivByZero or losing meaning as Integer = NaN
To inform you of a “oops…” look at that!
1 Like
Thank you @Rick_Araujo
Of course, one can try to prepare for such calculation errors, but even the most cautious users can miss situations where such errors lead to incorrect results. If machines (which may be working together with humans) are also being controlled, the consequences can be fatal.
But a DivisionByZero exception error would protect beginners and professionals alike from these errors. It probably wouldn’t make anyone’s life more difficult, but it would make life easier for many.
1 Like
agree to have this optional and care backwards compatibility.
That won’t happen. Nobody wants to only get certain exceptions if we enable them in the IDE settings or via a switch in the code. I, at least, would rather forgo implementation than have an exception thrown only optionally.
That’s a pretty sweeping statement. I think the Pragma suggestion is pretty sound - it strikes a balance between preserving existing behavior by default while providing an option for those who want it.
2 Likes
The special values NaN, INF, and -INF only exist for floating point data types so they cannot be converted to integer values. One could designate some integer values as NaN, INF, and -INF, respectively, so a conversion would be possible in principle, but I agree that it’s probably not worth the trouble.
Having said that one could argue that a division by 0 with integer values should cause an exception because the special values don’t exist for integers and one cannot test the results in retrospect with IsNotANumber or IsInfinite.
That’s how all this thread started and evolved to other aspects about this kind of problem.
One could, but not Xojo, and no computer language. In a computer language where integer is an object, those “values” would be set apart as flags, not in the value bits per se. So,no way, that’s… hmmm… 
. It would increase the mess. NaN, Inf± in floats does not consume its mantissa bits, they use a special “flag”, the exponent with all bits set + a mantissa meaning, the float structure has this ability with no equivalent in scalar integers.
No need to reinvent the wheel, exceptions handle that, just copy others.
2 Likes