Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62769
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.173 as permitted sender)
Message-ID: <504536BE.80309@sugarcrm.com>
Date: Mon, 03 Sep 2012 16:01:18 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120824 Thunderbird/15.0
MIME-Version: 1.0
To: Gustavo Lopes <glopes@nebm.ist.utl.pt>
CC: "internals@lists.php.net" <internals@lists.php.net>
References: <AANLkTimWuPXCs-HT6RgQYmH7UKcOYXkeTiMEnBwBXxnt@mail.gmail.com> <CAH-PCH4YdBr7WfQ2PR0_Fr_C=TfBsSGsbX3G-jonUqyfLrCcZQ@mail.gmail.com> <5040DC47.8000305@ajf.me> <CAH-PCH5TM2ag-5xm3Rk7Ef6LnpEst1UqRoc_f_Uwp_aLe418dA@mail.gmail.com> <5040F4D9.80206@sugarcrm.com> <CAEZPtU6X9gLRALzA+KGKNoF5c7ey-xgJ=0NhjF2qVfD9YJqN+Q@mail.gmail.com> <5042946A.80204@sugarcrm.com> <op.wjzdwn08idpuyk@damnation.nl.lo.geleia.net> <5042A7D6.7050001@lerdorf.com> <op.wjzgbuh1idpuyk@damnation.nl.lo.geleia.net> <alpine.DEB.2.02.1209031214250.25835@whisky.home.derickrethans.nl> <a565e97fdd574cebf2baca1c54c425a2@nebm.ist.utl.pt> <50452713.3020307@sugarcrm.com> <b6bf26cb6b4d2392d5fd13237669a19d@nebm.ist.utl.pt>
In-Reply-To: <b6bf26cb6b4d2392d5fd13237669a19d@nebm.ist.utl.pt>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: Are exceptions allowed in php core?
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> First, E_NOTICE exists to permit a compromise between people like Zeev 
> that think its introduction was an error and that one should be able to 
> refer to undefined variables and people who prefer a stricter model. For 
> the programmers that follow this stricter model, an E_NOTICE ends ups 
> frequently being a fatal (because, for instance, you invoke a method on 
> the resulting null); some other times you're lucky and you just missed 
> an "else $var = null" branch, other times the error is far more serious, 
> like an unintended null -> 0 conversion.

So it basically comes to "it doesn't follow but E_NOTICE in fact should
be fatal for those who prefer a stricter model because I had some code
where it indicated a bug". That's exactly what I was talking about. But
PHP is not designed to be this way and PHP code is not written this way,
for better or for worse. If you want to start a radical transformation
of PHP into something like Python where accessing a value in array that
doesn't exist (and pretty much any other unexpected thing) throws an
exception that finishes your application (or at least a segment of it
inside a catch-all-then-bail-out exception wrapper) - it should not be
done in a hush-hush case-by-case basis. It should be announced upfront
and consensus should be obtained. I personally do not see such
transformation as beneficial, and I suspect many others do not either.
But in any case this would not work on case-by-case basis.

If however we want to keep the current nature of PHP, introducing fatal
errors where it can be avoided only because it _may be_ a bug makes
little sense - we have tons of situations where it may be a bug - just
as you described with E_NOTICE and no fatal error there. We use fatal
error only when there's no logical exit from the situation - like you
tell to call a function and it doesn't exist - there's no default we
could substitute and there's no logical way to react on it. When we
access undefined variable though there is such way - we can assume the
variable is empty. We do the same with foreach() - if it's not iterable,
we assume no iteration happens. Can it be a bug? Sure it can. Do we
produce fatal error in this case? No we do not. Why we should start
doing it with generators? Just because they use iterator classes as
implementation detail? Doesn't make too much sense to me.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227