Since Xojo is restyling the coding syntaxes to more human and readable code, at least that was the intention, I should also expect some more human operation such as a runtime error when a divide by zero occurs.
I remember a there was a scientific approach to have it behaving as it does, but despite that i believe Xojo should follow Microsoft approach by raising a runtime error if the coder did not check for a divide by zero.
Anybody who has a good reason to keep it as it works now ?
This may help:
1 Like
i think if a cake is not cut the cake stay original
so a=12/0
i would expect 12.
createing a runtime error for everything is not a good approach.
that was the reason i wrapped every ms vb6 method into own one.
i used methods that return a boolean if they done the task, so you can control the app flow.
using try catch for all methods would make your code look very ugly.
at least xojo should raise a error in debug mode in ide for the developer.
at runtime in release mode i think the math operation should be ignored as mentioned above.
be careful, xojo could create different values for 32/64bit.
to be save you could calculate the divide by a method.
2 Likes
If there was some kind of runtime property that allowed the current functionality to be maintained then I guess it would be no problem allowing exceptions to be raised if the user wanted them.
If Xojo just changed functionality then it would be another backwards compatibility killer.
I don’t see how. It would just expose code that already isn’t working properly, no?
1 Like
It would expose code which isn’t handling it but would break code which is handling it.
1 Like
If code is handling it, it won’t divide by zero, so it won’t see any exception. Or do you mean something else?
2 Likes
Yes, checking the result afterwards.
n/0 is not possible, so the result is undefined, it’s not a number. Undefined can’t be expressed as an integer number and that’s why typed languages (besides Xojo) raises an exception when someone tries it. Float types can carry some special values, and for undefined values it is NaN (not -Inf or +Inf). Trying to set a NaN to an Integer should rise an exception. The reason that ignoring the exception and trying to attribute the bits of the value in the floating value of a NaN results in a large number is that NaN has an internal value with lots of bits set as 1, usually the signal, all the exponent bits, and part of mantissa, usually high bits. To be true, many people just set the higher 13 bits of 64 bit float (Double) when they need to express a NaN (NaN is a kind of value, not a constant, there’s not just ONE NaN value, there are millions of possible NaN combinations if you play with the lower bits.
let me explain different.
xojo could made optional settings how xojo behave, to make the developer happy.
see VB6 =Val(“Hello”) result in 0
see .net =Val(“Hello”) result in error (very unhandy) without error handling the app runs awhile and then it ■■■■■■up. (at wrong input)
How? There’s no safe form without an Exception during the math expression failing. The result silently transferred to an integer as possible real value (and probably kind of random) can’t be compared and assured being result of an invalid math operation. It just can make silent mess to those who don’t take proper previous measures (as usually do what Xojo calls “Citizen devs”).
It will break at this point, correct? As it should be.
.Net is a modern language where Exception handling is part of. So, if you can introduce errors in the expression, you can catch them and take actions. Let’s imitate VB6:
Try
x = Val(“Hello”)
Catch
x = 0
End Try
Dim v As Double
Dim v2 As Double
v = 5 / 0 * 5
v2 = Log(-1)
If Str(v) = "inf" Then
Break
End If
If IsInfMBS(v) = True Then
Break
End If
If Str(v2) = "nan" Then
Break
End If
If IsNANMBS(v2) = True Then
Break
End If
Break
“It will break at this point, correct? As it should be.”
no it should be bullet proved. if input is “” then it should return 0.
the developer know how to use the method as it is.
you can not make error handling for each piece of method you need to use.
have you considered what happens if you need this val 1000 times in your source code?
What is this?
You asked how you could detect it and I provided some very basic examples.
Not standard. Subject to fails. And worse, depends on plugins.
Couldn’t API 2 raise an exception like modern programmers expect and API 1 could be left alone. Just like everything else?
Nope that won’t work, we’d need a switch.
Breaking on unexpected errors as it does makes it. The VB6 (now defunct) behavior was fixed, not replicated.
The code shows how to do it without plugins.
FYI. I’m not against having it as a feature. I just think it should be a runtime switch and not forced upon users.