Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62768
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain nebm.ist.utl.pt from 193.136.128.21 cause and error)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Tue, 04 Sep 2012 01:00:01 +0200
To: <internals@lists.php.net>
Organization: =?UTF-8?Q?N=C3=BAcleo_de_Engenharia_Biom=C3=A9dica_do_Insti?=
 =?UTF-8?Q?tuto_Superior_T=C3=A9cnico?=
In-Reply-To: <5045266F.7000303@sugarcrm.com>
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>
 <5045266F.7000303@sugarcrm.com>
Message-ID: <47ddfb3c6842ca1fa92f6502e8d3504f@nebm.ist.utl.pt>
User-Agent: RoundCube Webmail/0.8-rc
Subject: Re: [PHP-DEV] Re: Are exceptions allowed in php
 =?UTF-8?Q?core=3F?=
From: glopes@nebm.ist.utl.pt (Gustavo Lopes)

Em 2012-09-03 23:51, Stas Malyshev escreveu:
>> I've replied here:
>> http://www.mail-archive.com/internals@lists.php.net/msg60706.html
>
> I have a feeling you're concocting a very far-reaching scenarios and
> making a lot of unbased assumptions there to arrive to pre-defined
> conclusions. Any programming error can cost a business money, and any
> problem can be fitted with scenario when it leads to blowing up whole
> world in the flames of global catastrophe, given enough imagination 
> and
> wild enough assumptions.

Sure. It's all a matter of degree. Like I said in the other reply, an 
accidental null -> 0 conversion can cause severe silent (no errors) 
problems, yet we do such automatic conversions. The question is what's 
to be gained vs. the additional risk. And there is little to no benefit 
in a model where rewinding a closed iterator is allowed, so the 
threshold for acceptable risk is very low. This is not a difficult case 
at all, IMHO.

> However, I do not see any technical reason - not involving 
> far-reaching
> assumptions following from nowhere - that require repeated generation
> produce a fatal error.

There is no strict technical reason  for most fatals in PHP too. Except 
maybe parser errors, you usually can abstain from doing whatever action 
would cause the fatal instead of raising the fatal. Calling function 
that does not exist or abstract method? Return NULL (like an invalid 
call btw).

> So far all the explanations seem to be to the
> tune of "because it's so bad!" but I don't see how it's worse than 
> any
> other fault - such as failing to open the file, database returning no
> results because of wrong query, etc. We do not produce fatal errors 
> on
> all of these cases - in fact, we produce fatal errors only when we 
> know
> there's no reasonable way to go on. I still do not see why just
> returning empty iterator with suitable warning does not fit the 
> pattern
> of all exceptional situations we have in PHP that are handled in a
> similar way.

The examples you do are not comparable. 1) They involve parts that the 
PHP programmer does not control and 2) they provide ways to detect the 
failure.

> For foreach() specifically, for example, you can put there
> invalid - non-iterable - value, and it won't be a fatal error. Why
> non-iterable value from generator should be a fatal error?
> I think it makes sense to treat it exactly like foreach() treats
> non-iterable values.

IMO, this is perhaps your strongest argument. But 1) that was a bad 
idea, 2) we're not really talking about the behavior of foreach(), we're 
talking about the behavior of specific methods that may or may not be 
called in the context of a foreach, in a hierarchy where exception 
throwing is well established. So it's not really analogous.

-- 
Gustavo Lopes