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

> Am 05.07.2015 um 00:50 schrieb Andrea Faulds <ajf@ajf.me>: > > 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?) At that point it's just a bit weird. The @ operator IMO shouldn't be the recommended way to handle fundamental operations. You ideally just check if the divisor is 0 and then do the operation. And at that point, we should just throw the DivisionByZeroError. Honestly, a warning is just the wrong thing to use. Either you enable it (like double division in C) or disable it completely (runtime exception in C). I can get behind both, but not behind a warning. Thanks, Bob.