Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:87024 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 17932 invoked from network); 5 Jul 2015 02:18:06 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Jul 2015 02:18:06 -0000 Authentication-Results: pb1.pair.com smtp.mail=bobwei9@hotmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=bobwei9@hotmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.93 as permitted sender) X-PHP-List-Original-Sender: bobwei9@hotmail.com X-Host-Fingerprint: 65.55.111.93 blu004-omc2s18.hotmail.com Received: from [65.55.111.93] ([65.55.111.93:52085] helo=BLU004-OMC2S18.hotmail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 7B/60-10992-CD398955 for ; Sat, 04 Jul 2015 22:18:05 -0400 Received: from BLU437-SMTP16 ([65.55.111.71]) by BLU004-OMC2S18.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Sat, 4 Jul 2015 19:18:01 -0700 X-TMN: [I4s4nNrCNYle48tTfX8lKDTtBn+C+P1Q] X-Originating-Email: [bobwei9@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail=_B94440C0-EEC8-4B36-BA0C-A3D2B31EEE92" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) In-Reply-To: Date: Sun, 5 Jul 2015 04:17:57 +0200 CC: PHP Internals References: <33BCE1D0-BA6D-464C-B23D-69AF71356111@ajf.me> <3932E76B-DC75-40CD-8B1A-B84F387707CC@ajf.me> <1EFE20ED-ED80-47D1-B697-58CA4359CA62@ajf.me> To: Sherif Ramadan X-Mailer: Apple Mail (2.2070.6) X-OriginalArrivalTime: 05 Jul 2015 02:17:59.0248 (UTC) FILETIME=[CFF63D00:01D0B6C8] Subject: Re: [PHP-DEV] Fix division by zero to throw exception (round 2) From: bobwei9@hotmail.com (Bob Weinand) --Apple-Mail=_B94440C0-EEC8-4B36-BA0C-A3D2B31EEE92 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" > Am 5.7.2015 um 01:52 schrieb Sherif Ramadan : > On Sat, Jul 4, 2015 at 7:30 PM, Bob Weinand > wrote: > At that point it's just a bit weird. The @ operator IMO shouldn't be = the recommended way to handle fundamental operations. >=20 > 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. > =20 > You ideally just check if the divisor is 0 and then do the operation. > And at that point, we should just throw the DivisionByZeroError. >=20 > 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=E2=80=99t the way to handle that. How would you = then handle it? Always force the user to check for 0? At exactly that point you=E2=80=99re indicating the user that there is = an error. (hence DivisionByZeroError and nothing like an exception) Errors IMO aren=E2=80=99t there to be handled (except logging etc.), but = to show a serious issue. Why don=E2=80=99t 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=E2=80=99t need a warning. Warnings are okay for external factors which shouldn=E2=80=99t 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). >=20 > 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=E2=80=9C. PHP defines the behavior of a division by zero to be either =C2=B1INF/NAN = (currently) or it will be well-defined in form of a thrown error. An Error is not "undefined". It=E2=80=99s well-defined when the Error is = thrown and when not. > I can get behind both, but not behind a warning. >=20 > 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=E2=80=99m 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.= --Apple-Mail=_B94440C0-EEC8-4B36-BA0C-A3D2B31EEE92--