> Am 05.07.2015 um 00:50 schrieb Andrea Faulds <a...@ajf.me>: > > Hey Sherif, > >> On 4 Jul 2015, at 21:56, Sherif Ramadan <theanomaly...@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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
