On Thu, Feb 24, 2011 at 10:29 AM, Ferenc Kovacs wrote:
> Hi.
>
> it was mentioned multiple times on the list, that exceptions from php core
> is prohibited.
> do we have some documentation about this?
> the more detailed email on this topic was from Lukas:
> http://www.mail-archive.com/internals@
On 31/08/12 13:47, Ferenc Kovacs wrote:
It was also mentioned in that thread that we already have a bunch of
exceptions in spl, and some of the spl features should be in the core (or
it is already in the core for example IteratorAggregate).
I personally don't see why SPL is separate from core PHP
On Fri, Aug 31, 2012 at 5:46 PM, Andrew Faulds wrote:
> On 31/08/12 13:47, Ferenc Kovacs wrote:
>
>> It was also mentioned in that thread that we already have a bunch of
>> exceptions in spl, and some of the spl features should be in the core (or
>> it is already in the core for example IteratorA
Ferenc,
>> Not for PHP 5.5 (if that's happening?), but for PHP 6 I think a lot of
> > things should become exceptions.
>
>
> From the impression that I get from reading through the mailing list
> threads and the irc discussions I think that there aren't that many things
> that could turn into exc
On Fri, Aug 31, 2012 at 7:03 PM, Anthony Ferrara wrote:
> Ferenc,
>
> >> Not for PHP 5.5 (if that's happening?), but for PHP 6 I think a lot of
>> > things should become exceptions.
>>
>>
>> From the impression that I get from reading through the mailing list
>> threads and the irc discussions I
Hi!
> The spl ext has exceptions all around, so if would count spl as "core", we
> have exceptions in the core already, so it would be ok to add more
> exceptions where appropriate.
SPL is not a part of basic language syntax. There are no SPL keywords
and no SPL classes used unless you explicitly
Ferenc Kovacs wrote:
I think it's fine for warnings, notices, and deprecations.
Yeah, continuing the execution and still being to handle/log multiple
notices is something that wouldn't be possible with exceptions.
I think it is a matter of identify where exceptions might be appropriate. On th
hi Stas,
On Fri, Aug 31, 2012 at 7:31 PM, Stas Malyshev wrote:
> Hi!
>
>> The spl ext has exceptions all around, so if would count spl as "core", we
>> have exceptions in the core already, so it would be ok to add more
>> exceptions where appropriate.
>
> SPL is not a part of basic language synt
Hi!
>> SPL is not a part of basic language syntax. There are no SPL keywords
>> and no SPL classes used unless you explicitly instantiate those classes.
>> So SPL is different.
>
> End users do not see nor buy the difference between what is Zend/ or
> what is ext/spl (or other) and can't be disab
Stas Malyshev wrote:
Well, not anybody's problem, each guy got his piece
committed, written in his favorite style, matching his unique use case,
and couldn't care less about anything else.
Sounds about right ...
I'm doing it this way and everybody has voted that it's OK so go whistle?
And we ha
On Sun, 02 Sep 2012 01:04:10 +0200, Stas Malyshev
wrote:
SPL is not a part of basic language syntax. There are no SPL keywords
and no SPL classes used unless you explicitly instantiate those
classes.
So SPL is different.
End users do not see nor buy the difference between what is Zend/ o
On 09/01/2012 04:51 PM, Gustavo Lopes wrote
> * In fact, if there is a unifying theme in the usage of exceptions in
> PHP, is that exceptions are used when OOP interfaces are involved (see
> Zend interfaces, SPL, DateTime and PDO -- though optional there). The
> core vs. non-core argument only loo
Hi!
> * If users do not expect exceptions in the core, they are mistaken. There
> are indeed exceptions in the core. See ZEND_FE_RESET and
> zend_interfaces.c. Of course, no evidence has been provided one way or
> another.
This is not right either, but that was done in 2005. We're now in 20
On Sun, 02 Sep 2012 02:27:02 +0200, Rasmus Lerdorf
wrote:
On 09/01/2012 04:51 PM, Gustavo Lopes wrote
* In fact, if there is a unifying theme in the usage of exceptions in
PHP, is that exceptions are used when OOP interfaces are involved (see
Zend interfaces, SPL, DateTime and PDO -- though
On Sun, 02 Sep 2012 02:37:50 +0200, Stas Malyshev
wrote:
* If users do not expect exceptions in the core, they are mistaken.
There are indeed exceptions in the core. See ZEND_FE_RESET and
zend_interfaces.c. Of course, no evidence has been provided one way or
another.
This is not right eit
Hi!
> More importantly, there is no other satisfactory solution (except a fatal
> error). foreach has no return value, so it has no other way to signal a
> failure. If we used a notice or a warning here what would happen is that
> code that used generators with an invalid state would, except
On 09/01/2012 05:44 PM, Gustavo Lopes wrote:
> More importantly, there is no other satisfactory solution (except a
> fatal error). foreach has no return value, so it has no other way to
> signal a failure. If we used a notice or a warning here what would
> happen is that code that used generators w
Rasmus Lerdorf wrote:
On 09/01/2012 05:44 PM, Gustavo Lopes wrote:
More importantly, there is no other satisfactory solution (except a
fatal error). foreach has no return value, so it has no other way to
signal a failure. If we used a notice or a warning here what would
happen is that code that
On Sun, 02 Sep 2012 03:01:06 +0200, Stas Malyshev
wrote:
For me, it behaves exactly like any other
iterator would behave if you had no more useful elements in it -
meaning, producing no elements. I do not understand why you think it
requires immediate break of the code flow and abandoning the
hi!
On Sun, Sep 2, 2012 at 1:04 AM, Stas Malyshev wrote:
> Hi!
>
>>> SPL is not a part of basic language syntax. There are no SPL keywords
>>> and no SPL classes used unless you explicitly instantiate those classes.
>>> So SPL is different.
>>
>> End users do not see nor buy the difference betwee
On Sun, 2 Sep 2012, Gustavo Lopes wrote:
> On Sun, 02 Sep 2012 02:27:02 +0200, Rasmus Lerdorf wrote:
>
> > $things = getStuff();
> > foreach($things as $thing) {
> >do_some($thing);
> > }
> >
> > which is very normal PHP that you see in millions of lines of code, I
> > would not expect t
Derick Rethans wrote:
I think the first thing anyone who uses generators must understand is that
>they are iterators.
You forget that not even everybody that uses PHP knows what an iterator
is. For all they care, they have an array they can run foreach() on.
>They should be compared with itera
Em 2012-09-03 13:16, Derick Rethans escreveu:
I think the first thing anyone who uses generators must understand
is that
they are iterators.
You forget that not even everybody that uses PHP knows what an
iterator
is. For all they care, they have an array they can run foreach() on.
They sho
Hi!
> They are seen and promoted as core features. Whether we like that idea
> or not is not really relevant. We messed that up by making most of the
> "Standard" PHP Library an extension for only political and licensing
> reasons.
I think you using "core" here in two difference meanings, and the
Hi!
> 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 a
Hi!
> indicating such mental model is widespread and (2) given that the
> exceptions you claim to be surprising don't happen but for a programming
> error (i.e. they're not exceptions that need to be caught).
Following this logic, we'd have to convert all E_NOTICE and E_STRICT to
fatal errors o
Em 2012-09-03 23:54, Stas Malyshev escreveu:
Hi!
indicating such mental model is widespread and (2) given that the
exceptions you claim to be surprising don't happen but for a
programming
error (i.e. they're not exceptions that need to be caught).
Following this logic, we'd have to convert
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
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 u
Hi!
> 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.
We are discussing whether it should lead to the fatal error.
2012/9/4 Gustavo Lopes :
>> Following this logic, we'd have to convert all E_NOTICE and E_STRICT to
>> fatal errors or exceptions - they are usually produced by programming
>> errors and aren't meant to be caught by surrounding code (actually,
>> can't). But I don't see anybody benefiting from this
On 09/03/2012 04:31 PM, Alex Aulbach wrote:
> 2012/9/4 Gustavo Lopes :
>>> Following this logic, we'd have to convert all E_NOTICE and E_STRICT to
>>> fatal errors or exceptions - they are usually produced by programming
>>> errors and aren't meant to be caught by surrounding code (actually,
>>> ca
On Tue, 04 Sep 2012 01:27:12 +0200, Stas Malyshev
wrote:
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.
We are discu
2012/9/4 Rasmus Lerdorf :
> On 09/03/2012 04:31 PM, Alex Aulbach wrote:
>> 2012/9/4 Gustavo Lopes :
Following this logic, we'd have to convert all E_NOTICE and E_STRICT to
fatal errors or exceptions - they are usually produced by programming
errors and aren't meant to be caught by su
34 matches
Mail list logo
