2015-07-04 22:56 GMT+02:00 Sherif Ramadan <theanomaly...@gmail.com>: > 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.
+1, I fully agree. It's not exceptional, but it's potentially buggy code and should therefore produce a warning instead of just returning INF. I assume, most developers don't want to deal with INF in their code. If there's a warning, they can convert it to an exception which would not be possible without it. Regards, Niklas
