Re: Fix division by zero to throw exception (round 2)

Hey Sherif, > On 4 Jul 2015, at 21:56, Sherif Ramadan <theanomaly.is@gmail.com> wrote: > > I'm proposing that we reconsider removing the warning from floating point division and > here's why. > > While IEEE 754 defines special values for floating point arithmetic when division by zero > occurs, there's nothing stopping the language from providing useful error information to the > user, which may help them debug potentially buggy code. It's true that it's not > exceptional since there is now well defined behavior in the case of changing division by zero to > IEEE 754 standard in PHP. However, PHP didn't actually distinguish between integer division and > floating point division prior to intdiv. So in the case of division by zero the warning was useful > to help someone catch their mistake. > > Now, the onus is on the person writing the code to decipher whether or not they created a > potential division by zero scenario by deducing how they arrived at INF at some point in their code. > This is creating an unnecessary burden when we've always provided the user with the useful > error information in the past. I'm not sure why we should remove it now, but based on this > conversation I can see that the confusion resonates around this urge to convert the warning to an > exception and the conflict of it not being exceptional (in the case of floating point math) since > there is now well defined behavior. > > So my conclusion is that... > > Yes, it's not exceptional. No, we shouldn't throw an exception for division by zero > in floating point arithmetic. No, we shouldn't remove the warning since it still provides > useful information to the person debugging the code. Debugging the code without this warning can be > a monstrosity since you won't necessarily know at which point in a compounded operation the > division by zero occurred. For example, PHP_INT_MAX ** PHP_INT_MAX creates an overflow resulting in > INF. Though 0 / INF results in 0. So an operation like (1 / ($x / PHP_INT_MAX ** PHP_INT_MAX) where > $x happened to be 0 in one particular case, makes both hunting down and reproducing the bug quite > difficult without some direction. The warning has historically provided this direction in the past > and I believe that removing it now will only further the confusion. > > I don't think people actually care about whether or not we keep the warning. I think what > they would care about more is the consistency of the return value and defined behavior, which I > believe we have already addressed very well. Yeah, keeping it around makes sense. Thing is, if it’s a problem, you can silence it with @, so @($a / $b). If that’s slow, we could optimise it (make it call div_function_no_error or something?) Thanks. -- Andrea Faulds http://ajf.me/