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:
internals@lists.php.net/msg43237.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg43237.html
"Generally we have decided to leave Exceptions out of core with a few
"exceptions":
- errors in the constructor will throw an exception
- extensions may choose to offer an Exception mode (see PDO)
I never understood why we did 1), if a constructor can fail, then a factory
should be used instead. But oh well. With 2) you are obviously also opening
a pandoras box, that is similar to using a global error handler that turns
all Notices, Warnings etc as Exception: you can easily break code that calls
various libraries .. take for example passing in a PDO instance to one
library which expects the normal error mode and another one that enables the
Exception mode. For the most part however we can conclude that most
libraries enable the Exception mode in PDO and I think you will be hard
pressed to find any PDO code example that doesn't assume that the Exception
mode is enabled. "
every other mention about this topic is in-general prohibits the usage of
exceptions.
internals@lists.php.net/msg49637.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg49637.html
internals@lists.php.net/msg44159.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg44159.html
so I would like to know, that what is the current situation, and do these
mails still holds true.
maybe things has changed.
Tyrael
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:
internals@lists.php.net/msg43237.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg43237.html"Generally we have decided to leave Exceptions out of core with a few
"exceptions":
- errors in the constructor will throw an exception
- extensions may choose to offer an Exception mode (see PDO)
I never understood why we did 1), if a constructor can fail, then a
factory should be used instead. But oh well. With 2) you are obviously also
opening a pandoras box, that is similar to using a global error handler
that turns all Notices, Warnings etc as Exception: you can easily break
code that calls various libraries .. take for example passing in a PDO
instance to one library which expects the normal error mode and another one
that enables the Exception mode. For the most part however we can conclude
that most libraries enable the Exception mode in PDO and I think you will
be hard pressed to find any PDO code example that doesn't assume that the
Exception mode is enabled. "every other mention about this topic is in-general prohibits the usage of
exceptions.
internals@lists.php.net/msg49637.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg49637.html
internals@lists.php.net/msg44159.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg44159.htmlso I would like to know, that what is the current situation, and do these
mails still holds true.
maybe things has changed.Tyrael
Sorry for bringing up this thread, but based on the recent mails from
Derick it seems to me that there is/was some agreement that core features
shouldn't throw exceptions.
internals@lists.php.net/msg60631.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg60631.html
internals@lists.php.net/msg60635.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg60635.html
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).
Personally I think that OOP features should be allowed to throw Exceptions,
and I think that it would still in line with the our users expectations.
The only problem that I can think of is that for some stuff, we have both a
procedural and an oop API, but I'm not proposing turning everything into
Exceptions, but using them where appropriate.
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, especially
since it's required. Why must the core not have OO stuff, but have
non-OO stuff?
Personally I think that OOP features should be allowed to throw Exceptions,
and I think that it would still in line with the our users expectations.
The only problem that I can think of is that for some stuff, we have both a
procedural and an oop API, but I'm not proposing turning everything into
Exceptions, but using them where appropriate.
Not for PHP 5.5 (if that's happening?), but for PHP 6 I think a lot of
things should become exceptions. I don't think that, personally, PHP's
current error handling system is sufficient for properly handling
errors. I think it's fine for warnings, notices, and deprecations. It's
well suited to that kind of thing, and for that it should be kept (along
with completely fatal core errors, where instantiating an object is
inappropriate or impossible.) And yes, I think there should be
exceptions in core PHP where appropriate
But for handling actual errors, e.g. being unable to open a file, or
failing to initialise something, Exceptions are far better suited to the
task. Especially where the error is non-fatal and you may wish to catch
it and do something else (for instance, if a file didn't exist, you
could create a new one, perhaps).
Also, I think PHP's keep-calm-and-carry-on attitude to some errors at
the moment actually makes things harder, since it will often keep going,
leaving behind some NULL value, when it would be much easier to debug if
it stopped since then you don't have a strange undefined application
state. But that's just my opinion :)
--
Andrew Faulds
http://ajf.me/
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, especially since
it's required. Why must the core not have OO stuff, but have non-OO stuff?
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.
About OOP vs procedural: as I explained, we should still only use
exceptions in the core where it is appropriate, if somebody sees a
procedural api, he/she could be surprised if said api starts mixing OOP
here through throwing exceptions around. On the other hand when somebody
uses OOP features it would be natural for him/her that there could be
exceptions on the way.
Personally I think that OOP features should be allowed to throw
Exceptions,
and I think that it would still in line with the our users expectations.
The only problem that I can think of is that for some stuff, we have both
a
procedural and an oop API, but I'm not proposing turning everything into
Exceptions, but using them where appropriate.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 exceptions.
E_RECOVERABLE_ERROR and probably that's it.
I don't think that, personally, PHP's current error handling system is
sufficient for properly handling errors.
It is working for years, it could be improved but I wouldn't call it
insufficient.
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.
It's well suited to that kind of thing, and for that it should be kept
(along with completely fatal core errors, where instantiating an object is
inappropriate or impossible.) And yes, I think there should be exceptions
in core PHP where appropriate
Agree on both cases, but please don't turn this thread into discussing the
viability of turning the php current error handling into exceptions, we
have threads for that.
This thread is about whether or not it is fine for a (new)core feature to
throw exceptions if appropriate.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
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 exceptions.
E_RECOVERABLE_ERRORand probably that's it.
Actually, from my look at it, almost all E_WARNINGs, a number of E_NOTICEs
(the ones that make sense to transition, like array to string cast),
E_RECOVERABLE and certain E_ERROR (such as call to undefined method, etc)
can be turned pretty easily. The ones that can't (without significant
change to the engine at least) are deeper E_ERROR, E_CORE_*, and E_PARSE...
Take a look at the library I am linking to deeper down. All of those errors
are core thrown errors that can be easily turned into exceptions. Plus the
E_ERROR that I couldn't, but we can in core (again, call to undefined
method, etc)...
I don't think that, personally, PHP's current error handling system is
sufficient for properly handling errors.It is working for years, it could be improved but I wouldn't call it
insufficient.
Any system where it's harder to handle the error properly than to
ignore it is insufficient in my book. The fact that you need something like
this: https://github.com/ircmaxell/ErrorExceptions to handle errors
properly as exceptions (to be notified not that an error occured, but the
type of error) is indicative of that...
Anthony
On Fri, Aug 31, 2012 at 7:03 PM, Anthony Ferrara ircmaxell@gmail.comwrote:
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 exceptions.
E_RECOVERABLE_ERRORand probably that's it.Actually, from my look at it, almost all E_WARNINGs, a number of E_NOTICEs
(the ones that make sense to transition, like array to string cast),
E_RECOVERABLE and certainE_ERROR(such as call to undefined method, etc)
can be turned pretty easily. The ones that can't (without significant
change to the engine at least) are deeper E_ERROR, E_CORE_*, and E_PARSE...Take a look at the library I am linking to deeper down. All of those
errors are core thrown errors that can be easily turned into exceptions.
Plus theE_ERRORthat I couldn't, but we can in core (again, call to
undefined method, etc)...I don't think that, personally, PHP's current error handling system is
sufficient for properly handling errors.It is working for years, it could be improved but I wouldn't call it
insufficient.Any system where it's harder to handle the error properly than to
ignore it is insufficient in my book. The fact that you need something like
this: https://github.com/ircmaxell/ErrorExceptions to handle errors
properly as exceptions (to be notified not that an error occured, but the
type of error) is indicative of that...Anthony
sigh.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
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 instantiate those classes.
So SPL is different.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
hi Stas,
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 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 disabled, like SPL.
I really think we should consider exceptions, step by step, for the
language itself, when it makes sense. And the generators RFC is one
case where exceptions make sense (no cross discussion posting, only
for the record here).
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
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 disabled, like SPL.
Of course they'd see it. Here it goes again: "There are no SPL keywords
and no SPL classes used unless you explicitly instantiate those
classes". You can not just write some plain PHP syntax and end up having
SPL class. If you use SPL class, you must do "new SplSomeClass" or
something similar. It has nothing to do with disabling.
I really think we should consider exceptions, step by step, for the
language itself, when it makes sense. And the generators RFC is one
We should consider them, but we should not do it in ad-hoc manner. It
doesn't work ad hoc - this is exactly what keeps giving PHP users grief
and PHP as a project reputation of environment that makes no sense -
introducing stuff in random places without regard to how other parts of
the language work. Why this piece has exceptions and that doesn't? Oh,
that's because one guy implemented that part, another guy implemented
this, they didn't want to get to agreement on this, so they just did
completely different things in two places. And how the user is expected
to work with both? 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.
This is not how language environment should be properly designed. When
(and if) we have a model of using exceptions in core, then we can
introduce them in core, but introducing them piecemeal in random places
just because people fell like it, without any plan or design is just not
right. We have to stop doing it.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
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 have another 'use' that makes removing exceptions even more difficult.
This needs to be PLANNED, and documented fully ... not just bolted in because
someone thinks it's a good idea!
Look at the whole picture rather than adding piecemeal changes which then
'dictate' that other inappropriate changes should happen 'to be consistent'. PHP
is NOT like compiled languages and so we don't want to loose it's fundamentally
different features just because someone thing it should look like X as well.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
On Sun, 02 Sep 2012 01:04:10 +0200, Stas Malyshev smalyshev@sugarcrm.com
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/ or
what is ext/spl (or other) and can't be disabled, like SPL.Of course they'd see it. Here it goes again: "There are no SPL keywords
and no SPL classes used unless you explicitly instantiate those
classes". You can not just write some plain PHP syntax and end up having
SPL class. If you use SPL class, you must do "new SplSomeClass" or
something similar. It has nothing to do with disabling.
This is thoroughly unconvincing. Let me see if I got this:
Users do not expect exceptions in the core. They distinguish the core from
the rest because the core is what they interact it when they "use only PHP
syntax" (itself an odd statement, but let's let it pass).
This argument has at least these shortcomings:
-
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. -
Most ext/spl classes are not prefixed. If you ask the average PHP
developer to tell between Iterator, IteratorAggregate, RecursiveIterator,
ArrayAccess and Serializable, which are core and which are ext/spl, I
doubt many would get the answer right. Not that they should care. -
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 looks attractive because there are few built-in
classes in the core.
To be sure, there's one important distinction between core and ext/spl.
ext/spl should depend on core, not the other way around. Which has little
relevance for this discussion.
--
Gustavo Lopes
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 looks attractive because there are few
built-in classes in the core.
I think this is drifting off-topic. Whether or not a generator is an
object is an implementation detail. If I write:
$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 to have to wrap my foreach in a try/catch here. Even if
I am used to exceptions and might have:
$things = getStuff();
foreach($things as $thing) {
try {
do_some($thing);
} catch (Exception $e) {
echo $e->getMessage();
}
}
this is still going to fatal on me eventually with an uncaught exception
on the foreach if, for example, I pass the generator a second time to
something and it has run off the end. This is something you don't have
to worry about currently and I think it will cause headaches for people
when they start passing generators around. In theory I should be able to
pass a generator to any existing code that takes an array without having
to worry about modifying that code to catch foreach exceptions. And yes,
I know it is actually a generator exception, but to the average user it
will look like it is foreach throwing.
-Rasmus
On Sun, 02 Sep 2012 02:27:02 +0200, Rasmus Lerdorf rasmus@lerdorf.com
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 optional there). The
core vs. non-core argument only looks attractive because there are few
built-in classes in the core.I think this is drifting off-topic. Whether or not a generator is an
object is an implementation detail.
My message is certainly on-topic for this thread. But you are right in
that correct line of inquiry for the generator error condition is whether
an exception/fatal error is appropriate in this situation, not whether
exceptions are allowed in the core. For the reasons I explain next, I
think it is.
$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 to have to wrap my foreach in a try/catch here.
[...]this is still going to fatal on me eventually with an uncaught exception
on the foreach if, for example, I pass the generator a second time to
something and it has run off the end. This is something you don't have
to worry about currently and I think it will cause headaches for people
when they start passing generators around. In theory I should be able to
pass a generator to any existing code that takes an array without having
to worry about modifying that code to catch foreach exceptions. And yes,
I know it is actually a generator exception, but to the average user it
will look like it is foreach throwing.
I think the first thing anyone who uses generators must understand is that
they are iterators. They should be compared with iterators, not arrays.
With that in mind, the behavior is not surprising for anyone who knows how
iterators and foreach interact.
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 for the
notice, work as if it had been given an empty iterator. Put another way,
it would fail with only a notice, and continue. That is a far more serious
problem. In other circumstances where we emit warnings, we usually have a
return value the caller can check for error conditions.
--
Gustavo Lopes
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 for the
notice, work as if it had been given an empty iterator. Put another way,
it would fail with only a notice, and continue. That is a far more serious
problem. In other circumstances where we emit warnings, we usually have a
return value the caller can check for error conditions.
I'm not sure I understand why you think behaving as it is an empty
iterator and producing an error message is "far more serious problem".
Could you explain that? 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 execution
of the current function - after all, for the surrounding code the
situation where iterator has no elements is a normal situation for an
iterator, and iterating twice is indistinguishable - from the POV of the
surrounding code - from iterating an empty iterator once. Moreover, if
foreach() was supposed to have any side effects, none of these effects
would happen with empty return, so there's no danger here either. So I
believe the point that this condition requires immediate exit from the
code flow needs some explanation.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
On Sun, 02 Sep 2012 03:01:06 +0200, Stas Malyshev smalyshev@sugarcrm.com
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 execution
of the current function - after all, for the surrounding code the
situation where iterator has no elements is a normal situation for an
iterator, and iterating twice is indistinguishable - from the POV of the
surrounding code - from iterating an empty iterator once. Moreover, if
foreach() was supposed to have any side effects, none of these effects
would happen with empty return, so there's no danger here either. So I
believe the point that this condition requires immediate exit from the
code flow needs some explanation.
Precisely. The fact that everything happens normally except for the
iterator giving out an empty set is what makes this an insidious problem.
The request will be fully processed, but you will have a bug that may
manifest itself in a relatively safe manners (e.g. a search page giving no
results) -- though that could possibly cost a business money -- or in far
more destructive manners (for instance, if the iterator was to return a
set of files or database entities to keep when deleting others).
--
Gustavo Lopes
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 for the notice, work as if it had been given an empty iterator.
Put another way, it would fail with only a notice, and continue. That is
a far more serious problem. In other circumstances where we emit
warnings, we usually have a return value the caller can check for error
conditions.
This is the real question here. It actually isn't about Exceptions at
all. It is whether trying to iterate a closed generator should be a
fatal error that breaks script execution right then and there. Whether
that is done as an exception or a fatal error isn't actually all that
relevant since the end result will be the same for most people. If
everyone is in agreement that this should be a fatal error (I don't
personally get why it has to be fatal) then lets just make it a fatal
error and when we come up with a decent proposal for turning recoverable
fatals into exceptions language-wide we can revisit this. And this might
even be in the same release, so...
-Rasmus
Rasmus Lerdorf 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 with an invalid state would,
except for the notice, work as if it had been given an empty iterator.
Put another way, it would fail with only a notice, and continue. That is
a far more serious problem. In other circumstances where we emit
warnings, we usually have a return value the caller can check for error
conditions.This is the real question here. It actually isn't about Exceptions at
all. It is whether trying to iterate a closed generator should be a
fatal error that breaks script execution right then and there. Whether
that is done as an exception or a fatal error isn't actually all that
relevant since the end result will be the same for most people. If
everyone is in agreement that this should be a fatal error (I don't
personally get why it has to be fatal) then lets just make it a fatal
error and when we come up with a decent proposal for turning recoverable
fatals into exceptions language-wide we can revisit this. And this might
even be in the same release, so...
Finally I'm understanding what my problem is with a lot of this stuff.
I kept looking at this and trying to understand exactly WHAT the flow through
the code is. The 'magic' processing of generators is hiding away exactly where
the source of a problem is. Showing me the code that is carrying out the
processing, rewind, next etc ... at lease allows me to understand just what is
throwing a problem when it happens - and handling the error! And yes an
exception that gives a accurate error report is the only way of handling that
without the visible code steps to error against? So we are back to the
fundamental problem of how does one HANDLE that exception in an environment
where they are currently only used in limited specific actions ... which may
also be wrong! ...
I prefer to code for and capture errors, so if the file does not exist I check
for that and give the user a suitable warning. If I'm iterating a file and the
read does not complete becuase of an OS read fault I like to capture that state
and handle it. I can accept generators IF I can bail out with a suitable error
when I need to, but exceptions are there simply because no one bothered to
handle the real error? The work flow has been so screwed up that the only way
out is to crash?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
$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 to have to wrap my foreach in a try/catch here.
[...]this is still going to fatal on me eventually with an uncaught exception
on the foreach if, for example, I pass the generator a second time to
something and it has run off the end. This is something you don't have
to worry about currently and I think it will cause headaches for people
when they start passing generators around. In theory I should be able to
pass a generator to any existing code that takes an array without having
to worry about modifying that code to catch foreach exceptions. And yes,
I know it is actually a generator exception, but to the average user it
will look like it is foreach throwing.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 iterators, not arrays.
They shouldn't be compared with either. They are magical things that
happen with a "yield" keyword.
With that in mind, the behavior is not surprising for anyone who knows
how iterators and foreach interact.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 for the notice, work
as if it had been given an empty iterator. Put another way, it would fail with
only a notice, and continue.
Continue doing what?
cheers,
Derick
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 iterators, not arrays.
They shouldn't be compared with either. They are magical things that
happen with a "yield" keyword.
Seconded ...
But hiding things behind 'magic' is the problem here :(
Personally for 'generators' to be any use to me I need to be able to ask them
what is wrong rather than be blown out somewhere else because something
unexpected happened. If it was a data stream then I'd just check $gen->error();
or $gen->noofrows to see what had happened ... nothing magic at all. But using
magic necessitates exceptions since there is no other way of handling the
errors? Is there no way we can 'check the state' of a generator in-line ...
$gen->status for example? Surely this is just a matter of passing an 'at end of
file' flag for example where you ARE reading an empty generator? Rather than
just bailing out to an exception?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
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 should be compared with iterators, not arrays.
They shouldn't be compared with either. They are magical things that
happen with a "yield" keyword.
OK, you prefer to replace the facts (generators are iterator objects
and they are introduced as such) with an alternative reality that
putatively exists (or will exist) in the users' mind. I have no interest
in a discussion in those terms, especially (1) without any evidence
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).
With that in mind, the behavior is not surprising for anyone who
knows
how iterators and foreach interact.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 for the
notice, work
as if it had been given an empty iterator. Put another way, it would
fail with
only a notice, and continue.Continue doing what?
I've replied here:
internals@lists.php.net/msg60706.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg60706.html
--
Gustavo Lopes
Hi!
I've replied here:
internals@lists.php.net/msg60706.html" rel="nofollow" target="_blank">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.
However, I do not see any technical reason - not involving far-reaching
assumptions following from nowhere - that require repeated generation
produce a fatal error. 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. 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.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Em 2012-09-03 23:51, Stas Malyshev escreveu:
I've replied here:
internals@lists.php.net/msg60706.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg60706.htmlI 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
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. I see no
reason for that and declaring "it's not difficult" does not make a
reason a bit clearer. There should be a reason for generating fatal
error, and "this may be a bug" is not a reason enough, at least not in
PHP, as long established practice in PHP clearly shows.
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? ReturnNULL(like an invalid
call btw).
Returning null is a legitimate function return, and there's no value
that can not be legitimately returned from an existing function.
Moreover, since unlike empty iterator, not calling a function is not
normal (iterators can be legitimately empty, but function can not be
legitimately non-existing) fatal error is a proper response to it. Of
course, if we used exceptions, there could be an exception thrown
instead, which is the same thing more or less.
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.
Sorry, but again I have a feeling that you are not satisfied in general
with how PHP handles errors and want much more strictness there. Which
is completely fine, but I must again emphasize that doing it by sneaking
exceptions here and there into the core is not the right way to do it.
If you want to change how PHP behaves, it should be done as a
language-level principle change, and not being done by altering bits of
random patches to behave how the "strict" people like and inconsistently
with how the rest of PHP behaves. I would be happy to discuss it, I have
a lot of issues with current error handling too, but we can not just
ignore the established principles.
If we have a behavior that can be used in two contexts and it is not
consistent with one of them, it is not good to point out it may be
consistent with another. Not throwing exception in this case is
consistent with all other PHP - nothing requires that generator or
iterator would throw exceptions on every problem. In fact, I do not
believe any of the existing iterators throw on trying to iterate past
the end. So not throwing will be consistent with everything.
However, throwing will be inconsistent with foreach() usage pattern and
only marginally consistent with other iterators - while they indeed
throw exceptions, as far as I can see they don't do it in normal
iteration scenarios, only when trying to pull something weird like
accessing keys of invalid iterator or when using underlying
functionality that fails. But as far as I can see you can not make any
of existing SPL iterators to throw by repeatedly iterating over them.
Even NoRewindIterator - which states "no rewind" in its name - does not
throw when you try to repeatedly iterate over it.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
On Tue, 04 Sep 2012 01:27:12 +0200, Stas Malyshev smalyshev@sugarcrm.com
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 discussing whether it should lead to the fatal error. I see no
reason for that and declaring "it's not difficult" does not make a
reason a bit clearer. There should be a reason for generating fatal
error, and "this may be a bug" is not a reason enough, at least not in
PHP, as long established practice in PHP clearly shows.
Yes, we are. I am saying that "reason" is a balancing of factors: (1)
whether the non-exception error behavior makes sense and (2) the extent it
has legitimate uses on one hand and, on the other hand (3) the risk it
introduces.
Of course different languages balance these factors differently and PHP
puts less emphasis on (3) -- I'm not trying to change that.
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? ReturnNULL(like an invalid
call btw).Returning null is a legitimate function return, and there's no value
that can not be legitimately returned from an existing function.
Moreover, since unlike empty iterator, not calling a function is not
normal (iterators can be legitimately empty, but function can not be
legitimately non-existing) fatal error is a proper response to it. Of
course, if we used exceptions, there could be an exception thrown
instead, which is the same thing more or less.
Your distinctions here make no sense to me. I cannot understand how the
first sentence is even an argument, but in any case you can also say,
"Returning an empty set is a legitimate iterator return, and there's no
set that cannot be legitimately returned from an existing iterator".
There's also no meaningful distinction after. It boils down to what you
consider "normal" and "legitimate", and for some reason you equate not
traversing an iterator and replacing it with an empty one as "normal" and
"legitimate", but not executing a function and replacing it with a null
returning one abnormal and illegitimate.
But I'm glad you think this way. It means that you accept that the
criterion for raising a fatal is not simply "will we segfault if we do
this?" or "can we continue parsing if we do this?", but it is instead more
nuanced, requiring us to evaluate the "normality" and "legitimacy" of
non-fatal behavior, as you put it.
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.Sorry, but again I have a feeling that you are not satisfied in general
with how PHP handles errors and want much more strictness there. Which
is completely fine, but I must again emphasize that doing it by sneaking
exceptions here and there into the core is not the right way to do it.
If you want to change how PHP behaves, it should be done as a
language-level principle change, and not being done by altering bits of
random patches to behave how the "strict" people like and inconsistently
with how the rest of PHP behaves. I would be happy to discuss it, I have
a lot of issues with current error handling too, but we can not just
ignore the established principles.
I think you're misrepresenting my position. I want strictness only in the
cases where the alternative behavior fails the balancing test I mention
above, a test you (at least to some extent) also support. In the other
e-mail you say:
So it basically comes to "it doesn't follow but
E_NOTICEin 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.
[...]
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 withE_NOTICEand no fatal error there.
My test is not whether it may be a bug, as I explained. Yes, E_NOTICEs
may indicate a bug. But many times they will not (esp. on templates).
Now, we may disagree on this, but I content that the situation we're
discussing is almost certainly a bug.
If we have a behavior that can be used in two contexts and it is not
consistent with one of them, it is not good to point out it may be
consistent with another. Not throwing exception in this case is
consistent with all other PHP - nothing requires that generator or
iterator would throw exceptions on every problem. In fact, I do not
believe any of the existing iterators throw on trying to iterate past
the end. So not throwing will be consistent with everything.
Nor are they supposed to to throw an exception in that case. Even though
we don't document in the manual, iterators return null when they have no
more elements. But let's look at rewind:
Rewinds back to the first element of the Iterator.
Making a no-op is a violation of the post-conditions rewind() is supposed
to offer. And yes, I know about NoRewindIterator, which is an aberration
-- classical circle is-an ellipse bad design.
In fact, I would have preferred that rewind() was not a part of Iterator,
but it's too late for that.
However, throwing will be inconsistent with foreach() usage pattern and
only marginally consistent with other iterators - while they indeed
throw exceptions, as far as I can see they don't do it in normal
iteration scenarios, only when trying to pull something weird like
accessing keys of invalid iterator or when using underlying
functionality that fails. But as far as I can see you can not make any
of existing SPL iterators to throw by repeatedly iterating over them.
Even NoRewindIterator - which states "no rewind" in its name - does not
throw when you try to repeatedly iterate over it.
I disagree that this is a normal iteration scenario. And AFAIK all SPL
iterators are rewindable, so it's normal we can't find examples on point.
--
Gustavo Lopes
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 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 - as I don't see
anybody benefiting from generator that will explode your application if
you touch it twice.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
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 all
E_NOTICEandE_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 - as I don't see
anybody benefiting from generator that will explode your application
if
you touch it twice.
That does not follow at all.
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.
Second, E_STRICT exists to encourage good OOP practices. There is a lot
of code that generates E_STRICT that does what it was intended to do
(ask Lester). By definition, code that's not supposed to generate
E_STRICT messages but does is buggy, but the fact that some code raises
an E_STRICT does not signal, by itself, a bug.
--
Gustavo Lopes
Hi!
First,
E_NOTICEexists 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, anE_NOTICEends 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
2012/9/4 Gustavo Lopes glopes@nebm.ist.utl.pt:
Following this logic, we'd have to convert all
E_NOTICEandE_STRICTto
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 - as I don't see
anybody benefiting from generator that will explode your application if
you touch it twice.
Nobody is forced to handle an notice-exception like a fatal exception.
A notice-exception can be created write something into an error-log
and tells PHP not to handle it any more (destroys itself). Could be
all done in the construction of the exception.
--
Alex Aulbach
2012/9/4 Gustavo Lopes glopes@nebm.ist.utl.pt:
Following this logic, we'd have to convert all
E_NOTICEandE_STRICTto
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 - as I don't see
anybody benefiting from generator that will explode your application if
you touch it twice.Nobody is forced to handle an notice-exception like a fatal exception.
A notice-exception can be created write something into an error-log
and tells PHP not to handle it any more (destroys itself). Could be
all done in the construction of the exception.
First, you got the quoting wrong. Please be more careful with that.
And second, huh? Uncaught exceptions are by definition fatal. There is
no such thing as a notice exception. If we go down that road refer to my
email describing condition error systems. Longer term I think a
condition system would make a lot of sense for PHP, but we definitely
don't want to introduce some sort of bastard non-fatal exception.
-Rasmus
2012/9/4 Rasmus Lerdorf rasmus@lerdorf.com:
2012/9/4 Gustavo Lopes glopes@nebm.ist.utl.pt:
Following this logic, we'd have to convert all
E_NOTICEandE_STRICTto
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 - as I don't see
anybody benefiting from generator that will explode your application if
you touch it twice.Nobody is forced to handle an notice-exception like a fatal exception.
A notice-exception can be created write something into an error-log
and tells PHP not to handle it any more (destroys itself). Could be
all done in the construction of the exception.First, you got the quoting wrong. Please be more careful with that.
Sorry, was written from very old laptop which has problems, when I mark text.
And second, huh? Uncaught exceptions are by definition fatal. There is
no such thing as a notice exception. If we go down that road refer to my
email describing condition error systems. Longer term I think a
condition system would make a lot of sense for PHP, but we definitely
don't want to introduce some sort of bastard non-fatal exception.
Maybe I had not the right words to describe, what I mean: I would like
to see both worlds (current error-handling and exceptions) in PHP -
just as I need it.
Your proposal sounds quite interesting. For example: If an SQL-query
fails, the query itself isn't normally very interesting (it's wrong,
ok). I need to know where it was created and how. The error is not in
the database, it's most times in the PHP-program...
--
Alex Aulbach
Gustavo Lopes wrote:
Second,
E_STRICTexists to encourage good OOP practices. There is a lot of code
that generatesE_STRICTthat does what it was intended to do (ask Lester). By
definition, code that's not supposed to generateE_STRICTmessages but does is
buggy, but the fact that some code raises anE_STRICTdoes not signal, by
itself, a bug.
And in hindsight I'd say this was one of the worst decisions made in the past !!!
Simply switching something off just to make code work again is just wrong how
ever you look at it. This 'strict' stuff should have been handled with a bit
more intelligence such as providing a report as to non-compliant code which
picks up all the 'style differences' rather than having to work through layer
after layer of errors. My converted code is messy and does now need a 'style
tidy' clean-up. And I'm still not happy that what I AM doing the right things
anyway!
How many of the major PHP user projects ARE currently strict compliant? And how
many are still requiring E_STRICT switched off in PHP5.4?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
hi,
How many of the major PHP user projects ARE currently strict compliant? And
how many are still requiringE_STRICTswitched off in PHP5.4?
This is a development and very useful. PHP does not enforce this mode.
And like any other errors, it only ends in your logs.
But this has been told to you a good dozen of times in the past, and
it is really getting ridiculous to have to explain that over and over.
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Pierre Joye wrote:
How many of the major PHP user projects ARE currently strict compliant? And
how many are still requiring
E_STRICTswitched off in PHP5.4?
This is a development and very useful. PHP does not enforce this mode.
And like any other errors, it only ends in your logs.But this has been told to you a good dozen of times in the past, and
it is really getting ridiculous to have to explain that over and over.
And the point of YOUR comments?
With E_STRICT enabled - as is the default on PHP5.4 - programs simply crash if
they have not been 'converted'!
The QUESTION is a perfectly valid one ... especially when I've just hit yet
another current project that we have to make sure to disable E_STRICT when they
get transferred to a PHP5.4 machine! I have no doubt a lot more will also be
affected and so knowing the right answers is important. As perhaps is
understanding the reason some projects are not converting code?
While the preference on PHP5.4 may be to force people to comply, the reality is
that this is a switch which it's more likely needs switching off in production
simply because user land has no idea how to handle the problems yet. And I'll
keep banging on until what is distributed from the php.net site actually works
on a current default install ...
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Pierre Joye wrote:
How many of the major PHP user projects ARE currently strict compliant?
Andhow many are still requiring
E_STRICTswitched off in PHP5.4?This is a development and very useful. PHP does not enforce this mode.
And like any other errors, it only ends in your logs.But this has been told to you a good dozen of times in the past, and
it is really getting ridiculous to have to explain that over and over.And the point of YOUR comments?
WithE_STRICTenabled - as is the default on PHP5.4 - programs simply crash
if they have not been 'converted'!
E_STRICT can't crash you program. It's just like an E_WARNING or
E_NTOICE level error. It's non-fatal. It does not inhibit the
execution of code.
The QUESTION is a perfectly valid one ... especially when I've just hit yet
another current project that we have to make sure to disableE_STRICTwhen
they get transferred to a PHP5.4 machine! I have no doubt a lot more will
also be affected and so knowing the right answers is important. As perhaps
is understanding the reason some projects are not converting code?
What exactly is the question that you're posing to PHP Internals? An
audit of how much code doesn't follow strict standards? Probably a
lot. I've seen plenty of it in production myself and among them even
the most popular PHP frameworks. Having tested Joomla on PHP 5.4
before a switch to production I recall seeing an actual drop in
performance due to the sheer number of E_DEPRECATED and/or E_STRICT
errors that the code produced.
However, none of that prevented the code from running (or "crashing"
as you say). All you have to do is change the error_reporting
directive if you chose to ignore those errors for the time being. You
simply don't have display_errors on in production anyway so the worst
possible outcome here is that you end up with an error log stuffed
with those errors. Nothing critical here.
This is not even a minor concern for most code basis that exhibit this
problem to a great degree because the majority of them aren't willing
to upgrade to 5.4 or have realized the problem by now and are fixing
their code.
While the preference on PHP5.4 may be to force people to comply, the reality
is that this is a switch which it's more likely needs switching off in
production simply because user land has no idea how to handle the problems
yet. And I'll keep banging on until what is distributed from the php.net
site actually works on a current default install ...
The userland problem is a trivial issue. All they have to do is turn
display_errors off in production as is recommended and is the default
anyway. There is nothing major here to hold you back other than
yourself.
--
Lester Caine - G8HFLContact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Sherif Ramadan wrote:
Pierre Joye wrote:
How many of the major PHP user projects ARE currently strict compliant?
Andhow many are still requiring
E_STRICTswitched off in PHP5.4?This is a development and very useful. PHP does not enforce this mode.
And like any other errors, it only ends in your logs.But this has been told to you a good dozen of times in the past, and
it is really getting ridiculous to have to explain that over and over.And the point of YOUR comments?
WithE_STRICTenabled - as is the default on PHP5.4 - programs simply crash
if they have not been 'converted'!
E_STRICTcan't crash you program. It's just like anE_WARNINGor
E_NTOICE level error. It's non-fatal. It does not inhibit the
execution of code.
??? OH YES IT DOES !!!
MANY times I get a a few lines of text on a white screen ...
Switch off E_STRICT and everything works fine ... as it was on PHP5.2
The QUESTION is a perfectly valid one ... especially when I've just hit yet
another current project that we have to make sure to disableE_STRICTwhen
they get transferred to a PHP5.4 machine! I have no doubt a lot more will
also be affected and so knowing the right answers is important. As perhaps
is understanding the reason some projects are not converting code?What exactly is the question that you're posing to PHP Internals? An
audit of how much code doesn't follow strict standards? Probably a
lot. I've seen plenty of it in production myself and among them even
the most popular PHP frameworks. Having tested Joomla on PHP 5.4
before a switch to production I recall seeing an actual drop in
performance due to the sheer number ofE_DEPRECATEDand/orE_STRICT
errors that the code produced.
That is one which was white screening for me, and all I was trying to do was a
favour for some one. A quick hack of the config file and we were working again,
but certainly some modules in Joomla are not save when used withE_STRICTset!
However, none of that prevented the code from running (or "crashing"
as you say). All you have to do is change the error_reporting
directive if you chose to ignore those errors for the time being. You
simply don't have display_errors on in production anyway so the worst
possible outcome here is that you end up with an error log stuffed
with those errors. Nothing critical here.This is not even a minor concern for most code basis that exhibit this
problem to a great degree because the majority of them aren't willing
to upgrade to 5.4 or have realized the problem by now and are fixing
their code.
The 'concern' is that ISP's are following the recommendations, and using the
default production setup, so E_STRICT is on - PLEASE LEAVE IT OFF should be the
standard!
While the preference on PHP5.4 may be to force people to comply, the reality
is that this is a switch which it's more likely needs switching off in
production simply because user land has no idea how to handle the problems
yet. And I'll keep banging on until what is distributed from the php.net
site actually works on a current default install ...The userland problem is a trivial issue. All they have to do is turn
display_errors off in production as is recommended and is the default
anyway. There is nothing major here to hold you back other than
yourself.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
hi Lester,
??? OH YES IT DOES !!!
MANY times I get a a few lines of text on a white screen ...
Switch offE_STRICTand everything works fine ... as it was on PHP5.2
If you have any doubts about how to configure your development or
production servers, how to use logs or how to effectively debug php
applications, please ask questions on php-general or php-setup mailing
lists.
Thanks for your understanding,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
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 2012
and trying to make PHP a bit more orderly.
- 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 looks attractive because there are few built-in
classes in the core.
That's not my argument. My argument is when you instantiate some class
explicitly and work with it, you know you're dealing with certain API
that may include exceptions. When you're using foreach(), you don't
expect to wrap each foreach() into a try-catch block. But that's what is
happening here.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
On Sun, 02 Sep 2012 02:37:50 +0200, Stas Malyshev smalyshev@sugarcrm.com
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 either, but that was done in 2005. We're now in 2012
and trying to make PHP a bit more orderly.
The position that we should not use more exceptions in the core is of
course legitimate. But let's not temper with the factual record to make an
argument for it. This discussion should have started with an accurate
description of the current state.
- 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 looks attractive because there are few
built-in
classes in the core.That's not my argument. My argument is when you instantiate some class
explicitly and work with it, you know you're dealing with certain API
that may include exceptions. When you're using foreach(), you don't
expect to wrap each foreach() into a try-catch block. But that's what is
happening here.
I'm not sure what you're saying that is not your argument. What you cite
is an argument of mine, not yours. After that, you're basically saying the
same thing as Derick -- that because you're not instantiating a class
directly, you don't know that you're working with an object API that
includes exceptions. I don't really have a argument for that except that
users should know that generators return a sort of iterators.
But in any case, the argument that you have to wrap foreach() in try-catch
blocks is weak. That's like saying that in Java you have to try-catch
IllegalStateExceptions all the time. The truth is, correct code will never
throw these exceptions. As I explained in the reply to Rasmus' e-mail, a
fatal error would also be somewhat appropriate (though inconsistent with
the other Zend interfaces), but definitely a warning is not.
--
Gustavo Lopes
hi!
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 disabled, like SPL.Of course they'd see it. Here it goes again: "There are no SPL keywords
and no SPL classes used unless you explicitly instantiate those
classes". You can not just write some plain PHP syntax and end up having
SPL class. If you use SPL class, you must do "new SplSomeClass" or
something similar. It has nothing to do with disabling.
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 really think we should consider exceptions, step by step, for the
language itself, when it makes sense. And the generators RFC is oneWe should consider them, but we should not do it in ad-hoc manner. It
doesn't work ad hoc - this is exactly what keeps giving PHP users grief
and PHP as a project reputation of environment that makes no sense -
introducing stuff in random places without regard to how other parts of
the language work.
We can't really change existing code without breaking everything out
there. So we somehow have to do it on a case by case basis or for new
stuff only.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
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
question of political and licensing reasons is completely irrelevant to
current discussion. The question is that we have language core
(keywords, syntax constructs, etc.) and we have various APIs.
Unfortunately, due to disagreement among PHP developers, there's no
consistent policy among APIs on the question of how to handle errors.
However, there is a consistent policy about how to do it when we're
talking about core PHP constructs - keywords, language syntax, etc. -
that we do not use exceptions there.
We can't really change existing code without breaking everything out
there. So we somehow have to do it on a case by case basis or for new
stuff only.
We have to have clear policy that can be understood by users. Doing it
on a whim of a person that submits particular patch was what we were
doing before, and it didn't work very well for us. The consensus by this
point was that PHP keywords, language constructs, etc. do not throw
exceptions (the unfortunate patch of 2005 aside). If you want to change
this - fine, please propose a consistent policy that changes it, let's
agree on it and adopt it. But doing it in random places just because it
seemed convenient at this moment IMO is not a good idea. It is IMO
exactly what we are trying to fix.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
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 the
whole there is not a problem currently.
It's well suited to that kind of thing, and for that it should be kept
(along with completely fatal core errors, where instantiating an object is
inappropriate or impossible.) And yes, I think there should be exceptions
in core PHP where appropriateAgree on both cases, but please don't turn this thread into discussing the
viability of turning the php current error handling into exceptions, we
have threads for that.
This thread is about whether or not it is fine for a (new)core feature to
throw exceptions if appropriate.
Once again it's the 'if appropriate' rather than 'if necessary'?
Adding exceptions is another discussion, and I totally agree that in a few areas
then almost anything would be better than the current errors, but simply
returning an exception may not be necessary?
I am feeling that we are getting to a point where there needs to be two
different types of PHP. One that is basically OOP only and does not handle
procedural stuff, and for us old stick in the mud's a procedural base that
handles OO as it has in the past. Generators are an example of something that
when left open and used via the various functions simply makes following easier
than hiding everything away and just working by hidden magic. Exceptions have a
place in the right layer, just as warnings would have if a function was called
at the wrong point. Returning a suitable error number is just as valid as having
to wrap stuff in try statements simply because the function does not actually
handle an error condition? The Error handling brainstorming flagged up that the
reasons for using an exception are not understood, so we need to understand when
they are 'needed' rather then when 'appropriate'?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk