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

> On Jul 4, 2015, at 6:30 PM, Bob Weinand <bobwei9@hotmail.com> wrote: > > >> 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. > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php +1 In my opinion division by zero should result in some notification. I think a DivisionByZeroError seems the most appropriate. If a user wants the result of NaN or Inf it is trivial to write a function for that purpose. Perhaps PHP could provide such a function. Aaron Piotrowski