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

> Am 5.7.2015 um 01:52 schrieb Sherif Ramadan <theanomaly.is@gmail.com>: > On Sat, Jul 4, 2015 at 7:30 PM, Bob Weinand <bobwei9@hotmail.com > <mailto:bobwei9@hotmail.com>> wrote: > At that point it's just a bit weird. The @ operator IMO shouldn't be the recommended > way to handle fundamental operations. > > I don't think suppressing the error is any way of handling such error. I think that some > people just choose to ignore some errors in their code, but I doubt that's relevant to our > discussion here. My focus and primary concern is around providing people with useful information > that will help them debug their code. Ignoring that error isn't going to make it go away and > it's likely an indication of buggy code. So I I'd rather they get the error and then > decide for themselves whether or not they want to fix it or ignore it, rather than remove it > altogether. > > You ideally just check if the divisor is 0 and then do the operation. > And at that point, we should just throw the DivisionByZeroError. > > Why? The point of an exception is to say that the program/procedure can no longer continue at > this state and return control to the caller. If they are checking the divisor to prevent the > division by zero, why would they need an exception (i.e. why are they trying to catch that exception > to handle the division by zero specifically at some other part of the stack?). So, you say too @ isn’t the way to handle that. How would you then handle it? Always force the user to check for 0? At exactly that point you’re indicating the user that there is an error. (hence DivisionByZeroError and nothing like an exception) Errors IMO aren’t there to be handled (except logging etc.), but to show a serious issue. Why don’t we just return null with a warning on invalid function call and display a warning but throw Error? Null is the default return value of any function call. So, why not null? Return value just never was overwritten to be anything else, by the lack of the function which was called. Here we have exactly that same issue. Either something went really wrong (at that point you want to abort), or it is an intended feature, which doesn’t need a warning. Warnings are okay for external factors which shouldn’t influence program flow. If something changed in an unexpected way that will surely change the outcome of the program, then the only true handling is an Error. > 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'm not sure why you think it's wrong. It's useful and all of the reasons stated > so far indicate that division by zero is well-defined behavior. So there is no point in saying > "this behavior is undefined and PHP doesn't know what to do here so it's going to > throw an exception and let the user handle it“. PHP defines the behavior of a division by zero to be either ±INF/NAN (currently) or it will be well-defined in form of a thrown error. An Error is not "undefined". It’s well-defined when the Error is thrown and when not. > I can get behind both, but not behind a warning. > > I don't think that this ultimatum-esqueue attitude is necessarily conducive to objectively > examining the given problem or the discussion. I get that you may not find the warning to be > desirable, but that doesn't mean that it doesn't serve an objective purpose. The warning > makes perfect sense according to what's being discussed here since the Exception leaves us in > the boat of "the behavior is undefined". If we're going to throw an Exception than we > shouldn't return INF. It should remain undefined behavior. You can't have it both ways. I > believe this is the very inconsistency that people speak of when they make such complaints about > PHP. It's this uncanny desire for everyone working on some part of internals to force their > subjectivity on what should be an objective decision, because it doesn't just effect one or two > people. It effects countless people that rely on PHP. No ultimatum-esque attitude intended; I’m just saying that warning in the worst we can have. (see above for reasoning) Thanks, Bob P.s.: you forgot to CC internals in your last mail, doing so now.