Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87018
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.218 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAL+t6cGy=VFJ2+gHdQJjayc8927_u4p2SnU08nR_5bbC7sAzag@mail.gmail.com>
References: <CA+9eiLvd0YPKtED9CgU_thC9HUfTquaMJNf_9zQC0jyeX+rTuw@mail.gmail.com>
	<33BCE1D0-BA6D-464C-B23D-69AF71356111@ajf.me>
	<CA+9eiLsEDb-GuP4pRi-C8GQ2N+q7K=f-gmUMMxzxyy54CDy67w@mail.gmail.com>
	<3932E76B-DC75-40CD-8B1A-B84F387707CC@ajf.me>
	<CA+9eiLt3ScjNDuYLW=fLY2BUepzcRz=XPxbQCjSoy++0p67YNw@mail.gmail.com>
	<BLU437-SMTP1001E15E94ACA9AEE4676D6E2AA0@phx.gbl>
	<B4ACC432-714A-478B-9E1B-C9C532710598@ajf.me>
	<BLU436-SMTP121ED71E7D26AD9D99D9668E2AA0@phx.gbl>
	<1EFE20ED-ED80-47D1-B697-58CA4359CA62@ajf.me>
	<BLU436-SMTP69FBA3B51DA1D27C3A73A4E2970@phx.gbl>
	<CA+9eiLtZb+VNLNb_i0F+GfobroxffT50Sj564L64GSYmnRR2Sg@mail.gmail.com>
	<CAHvhOfj288YjxJXngVxULTgJo4QvWeo0=Zu3atwF3Mb-GeR+vQ@mail.gmail.com>
	<CAL+t6cGy=VFJ2+gHdQJjayc8927_u4p2SnU08nR_5bbC7sAzag@mail.gmail.com>
Date: Sat, 4 Jul 2015 23:09:24 +0200
Message-ID: <CANUQDCgdEABsjGwaRmHd+PViJLveTSL_nqZ4uZ8vhmd+EaRsGg@mail.gmail.com>
To: Sherif Ramadan <theanomaly.is@gmail.com>
Cc: =?UTF-8?B?SmFrdWIgS3Viw63EjWVr?= <kelerest123@gmail.com>, 
	Dmitry Stogov <dmitry@zend.com>, Bob Weinand <bobwei9@hotmail.com>, Andrea Faulds <ajf@ajf.me>, 
	PHP Internals <internals@lists.php.net>, Nikita Popov <nikita.ppv@gmail.com>, 
	Aaron Piotrowski <aaron@icicle.io>, Levi Morrison <levim@php.net>
Content-Type: multipart/alternative; boundary=047d7bacbed649b539051a131697
Subject: Re: [PHP-DEV] Fix division by zero to throw exception (round 2)
From: me@kelunik.com (Niklas Keller)

--047d7bacbed649b539051a131697
Content-Type: text/plain; charset=UTF-8

2015-07-04 22:56 GMT+02:00 Sherif Ramadan <theanomaly.is@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

--047d7bacbed649b539051a131697--