Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:87054 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 9920 invoked from network); 6 Jul 2015 16:43:49 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 6 Jul 2015 16:43:49 -0000 Authentication-Results: pb1.pair.com smtp.mail=theanomaly.is@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=theanomaly.is@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.46 as permitted sender) X-PHP-List-Original-Sender: theanomaly.is@gmail.com X-Host-Fingerprint: 209.85.215.46 mail-la0-f46.google.com Received: from [209.85.215.46] ([209.85.215.46:35986] helo=mail-la0-f46.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 4F/FE-21549-340BA955 for ; Mon, 06 Jul 2015 12:43:48 -0400 Received: by lagc2 with SMTP id c2so161667186lag.3 for ; Mon, 06 Jul 2015 09:43:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rnvnx9jK1Vurv5J0FBf2tLsb/s/wZAUaYt6MeazYXPw=; b=GV/8w+F726bzS25xC8GuXTZOGG7la2/Adwvu6/MudCKOl1BazH8obNm33Pa/b0M+iB 1d27Nuo8RbxV+62U/2f6jyB9dT2ohjUKIJyy4ryswfOUR6HpowSL6vryx0f4XGCuPdRp SlIXrDAwv1EIMb6d9LiE9q439Jp1b8T7q3OdRTkptT8bjh34oE/RJh/6NF5XJ1uI6TQy mreJfdpUe3QoyYiq9jjPnxZ5kEdcEcH0CHpk92lKt/24Hq7PKvgmr3fCesGyD435tv7I 6BYb9ydhv4I+V8z0HFPKr/bzMSXq2eiKLBHmrXYrBV2Zbo7m+SuBgihhePcVRt4hPNqD xNdQ== MIME-Version: 1.0 X-Received: by 10.112.146.36 with SMTP id sz4mr11841466lbb.54.1436201024355; Mon, 06 Jul 2015 09:43:44 -0700 (PDT) Received: by 10.25.35.216 with HTTP; Mon, 6 Jul 2015 09:43:44 -0700 (PDT) In-Reply-To: References: <0b1b01d0b752$ac7da0e0$0578e2a0$@belski.net> Date: Mon, 6 Jul 2015 12:43:44 -0400 Message-ID: To: Levi Morrison Cc: Anatol Belski , Ferenc Kovacs , Dan Ackroyd , =?UTF-8?B?SmFrdWIgS3Viw63EjWVr?= , Dmitry Stogov , Bob Weinand , Andrea Faulds , PHP Internals , Nikita Popov , Aaron Piotrowski , Kalle Sommer Nielsen Content-Type: multipart/alternative; boundary=047d7b3a82ace204ad051a379b4c Subject: Re: [PHP-DEV] Re: Revert unapproved language change, was: Fix division by zero to throw exception (round 2) From: theanomaly.is@gmail.com (Sherif Ramadan) --047d7b3a82ace204ad051a379b4c Content-Type: text/plain; charset=UTF-8 On Sun, Jul 5, 2015 at 4:39 PM, Levi Morrison wrote: > > > I just want to chime in and say that I have a contributed to a popular > application written in C that actually uses division by zero in a > useful manner. I feel like the rest of you think this is solely a > programmer error, and wanted to chime in to reiterate that this is not > the case. I would be in favor of removal of the error/warning and > *especially* would be against an exception for division by zero. > Division by zero as defined by IEEE 754 is actually useful which is > why it is often followed instead of sticking to a strict mathematical > definition where it is an error. > > I understand that some people are just upset about the > timing/discussion, which is possibly understandable - I have been too > busy lately to follow anything so I don't know. I just wanted to jump > in here and clarify the usefulness of what was actually changed. > IEEE 754 is useful, I agree. The warning is also useful, because it helps the programmer find their mistake more easily. It gives you a file name and line number to look for. We have to remember that PHP is being used by a wide array of people with varying skillsets and expertise. Not all of them know what IEEE 754 is or even how to prevent division by zero. When they don't debugging the code that results in a division by zero means having to learn those things first. We're lowering the bar by just handing them the useful debug information. So removing the warning makes no sense. Having a warning in your error log screams at you that you potentially have a bug here and PHP shines a light on it for you so that you can either fix it or refactor the code to not result in this potentially buggy behavior. I don't think the point of this discussion was to discuss which is more useful, the warning or the error/exception. My immediate concern for raising this issue, initially, was that we suddenly ended up in a place where we had neither a warning nor an error, thereby leaving the user with no useful debug information whatsoever. No indication that there is potentially buggy code. That's bad. That should not have happened. --047d7b3a82ace204ad051a379b4c--