Hey guys, 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. On Thu, Jul 2, 2015 at 4:44 AM, Jakub Kubíček <kelerest...@gmail.com> wrote: > +1 for everything proposed here :-) > > > Kubo2 > > > 2015-07-02 9:59 GMT+02:00 Dmitry Stogov <dmi...@zend.com>: > > On Thu, Jul 2, 2015 at 3:26 AM, Bob Weinand <bobw...@hotmail.com> wrote: > > > >> > Am 29.06.2015 um 19:14 schrieb Andrea Faulds <a...@ajf.me>: > >> > > >> > Hi again, > >> > > >> >> On 29 Jun 2015, at 18:02, Bob Weinand <bobw...@hotmail.com> wrote: > >> >> > >> >> Yes, it generally makes sense... > >> >> Then I have other questions: > >> >> > >> >> - Why do we then still have a Warning? Either we have well-defined > >> behavior, or we throw an exception. Well-defined behavior *plus* a > warning > >> is IMO non-sense. > >> > > >> > That’s weird, yeah. We don’t throw warnings for the math functions > when > >> you give them odd inputs, e.g. sin(INF) is just NAN, no warning. > >> > > >> > I think removing it would make sense. > >> > > >> >> - Is it intentional for intdiv and % to throw an Exception instead of > >> Error or some more specific DivisionByZeroError or similar? (yes, I > know, > >> Error is only very recent, but the question still needs to be asked). > >> > > >> > Hmm. Using Error might make some sense given it used to raise > E_WARNING. > >> I think DivisionByZeroError sounds like a good idea. > >> > >> Hey, > >> > >> I just committed that to master… > >> > >> But I noticed that intdiv(PHP_INT_MIN, -1) isn't very well suited for a > >> DivisionByZeroError. > >> > >> What do you think about adding an ArithmeticError for that case (and > >> making DivisionByZeroError subclass of it)? > >> That ArithmeticError could then be reused for negative bitshifts, which > >> would solve the question what to do with that too. > >> > > > > I think we should introduce ArithmeticError, as you propose. > > > > Thanks. Dmitry. > > > > > >> > >> Thanks, > >> Bob > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
