Re: [PHP-DEV] [RFC] Exceptions in the engine
Tony Marston wrote on 21/02/2015 10:08:
Nikita Nefedov wrote in message news:op.xuco5eutc9evq2@nikita-pc...
On Fri, 20 Feb 2015 12:39:33 +0300, Tony Marston
tonymars...@hotmail.com wrote:
I disagree. Exceptions were originally invented to solve the
semipredicate problem which only exists with procedural functions,
not object methods. Many OO purists would like exceptions to be
thrown everywhere, but this would present a huge BC break. If it
were possible get these functions to throw an exception ONLY when
they are included in a try ... catch block then this would not break
BC at all.
Tony, first of all - this still breaks BC, because exception is being
thrown in a place where it used not to be...
I disagree. The following function calls would not throw exceptions
fopen(...);
fwrite(...);
fclose(...);
while the following code would:
try {
fopen(...);
fwrite(...);
fclose(...);
} catch () {
}
But what about this code, which could well already exist:
try {
$fh = fopen(...);
$this-processLotsOfDataAndMaybeThrowAnException($fh);
fclose($fh);
} catch () {
}
If fopen() starts throwing exceptions here, that's as much a BC break as
it throwing them everywhere. If it doesn't, the rules for when it should
throw become even more complicated, and useful in even fewer cases.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
On Wed, Feb 25, 2015 at 4:19 PM, Rowan Collins rowan.coll...@gmail.com
wrote:
Tony Marston wrote on 21/02/2015 10:08:
Nikita Nefedov wrote in message news:op.xuco5eutc9evq2@nikita-pc...
On Fri, 20 Feb 2015 12:39:33 +0300, Tony Marston
tonymars...@hotmail.com wrote:
I disagree. Exceptions were originally invented to solve the
semipredicate problem which only exists with procedural functions, not
object methods. Many OO purists would like exceptions to be thrown
everywhere, but this would present a huge BC break. If it were possible get
these functions to throw an exception ONLY when they are included in a try
... catch block then this would not break BC at all.
Tony, first of all - this still breaks BC, because exception is being
thrown in a place where it used not to be...
I disagree. The following function calls would not throw exceptions
fopen(...);
fwrite(...);
fclose(...);
while the following code would:
try {
fopen(...);
fwrite(...);
fclose(...);
} catch () {
}
But what about this code, which could well already exist:
try {
$fh = fopen(...);
$this-processLotsOfDataAndMaybeThrowAnException($fh);
fclose($fh);
} catch () {
}
If fopen() starts throwing exceptions here, that's as much a BC break as
it throwing them everywhere. If it doesn't, the rules for when it should
throw become even more complicated, and useful in even fewer cases.
No. The proposal is only about fatal engine errors, like Fatal Error: Call
to undefined function %s().
Instead of script termination they will throw exceptions.
fopen() won't be touched at all. It's out of scope of proposal.
Thanks. Dmitry.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
On 25/02/15 13:19, Rowan Collins wrote:
Tony, first of all - this still breaks BC, because exception is being
thrown in a place where it used not to be...
I disagree. The following function calls would not throw exceptions
fopen(...);
fwrite(...);
fclose(...);
while the following code would:
try {
fopen(...);
fwrite(...);
fclose(...);
} catch () {
}
But what about this code, which could well already exist:
try {
$fh = fopen(...);
$this-processLotsOfDataAndMaybeThrowAnException($fh);
fclose($fh);
} catch () {
}
If fopen() starts throwing exceptions here, that's as much a BC break as
it throwing them everywhere. If it doesn't, the rules for when it should
throw become even more complicated, and useful in even fewer cases.
That is certainly the sort of scenario that I am concerned about.
try/catch blocks have been added through a lot of libraries and if the
returns now change then currently working code starts to fail. Fixing
the extra exceptions looks more interesting, so referring to the first
try block above, having to catch different exceptions from each function
is the problem here. But I still prefer dealing with the error as part
of the function call so I can at least respond in the same context.
--
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
Dmitry Stogov wrote on 25/02/2015 14:07: No. The proposal is only about fatal engine errors, like Fatal Error: Call to undefined function %s(). Instead of script termination they will throw exceptions. fopen() won't be touched at all. It's out of scope of proposal. Hi Dmitry, I was responding to a sub-thread where Tony Marston was requesting it be extended to other scenarios, and explaining why the idea of changing behaviour based on context would not work. I agree that the current proposal, for fatal errors only, does not constitute a significant BC break, particularly if the BaseException superclass is added. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
Pierre Joye wrote in message
news:CAEZPtU7vt=ppk4p3vfzflaepzi_wfr2hr_av+dtzvd6d2dz...@mail.gmail.com...
On Feb 21, 2015 2:08 AM, Tony Marston tonymars...@hotmail.com wrote:
Nikita Nefedov wrote in message news:op.xuco5eutc9evq2@nikita-pc...
On Fri, 20 Feb 2015 12:39:33 +0300, Tony Marston
tonymars...@hotmail.com
wrote:
I disagree. Exceptions were originally invented to solve the
semipredicate problem which only exists with procedural functions, not
object methods. Many OO purists would like exceptions to be thrown
everywhere, but this would present a huge BC break. If it were possible get
these functions to throw an exception ONLY when they are included in a try
... catch block then this would not break BC at all.
Tony, first of all - this still breaks BC, because exception is being
thrown in a place where it used not to be...
I disagree. The following function calls would not throw exceptions
fopen(...);
fwrite(...);
fclose(...);
while the following code would:
try {
fopen(...);
fwrite(...);
fclose(...);
} catch () {
}
When some function's result heavily depends on the context it makes said
function much harder to reason about. And creates mental overhead for those
who'll have to read the code with this function.
And again, if you need exceptions for fopen please consider using
SplFileObject.
For file usage, yes. But are there any other procedural functions without
an Spl* alternative which would benefit from this technique?
Expected failures should not raise exception. For example, IOs are expected
to fail (be network, filesystem etc), I would really not be in favor of
adding exceptions for similar cases. This is a normal control flow.
Pierre Joye wrote in message
news:CAEZPtU7vt=ppk4p3vfzflaepzi_wfr2hr_av+dtzvd6d2dz...@mail.gmail.com...
On Feb 21, 2015 2:08 AM, Tony Marston tonymars...@hotmail.com wrote:
Nikita Nefedov wrote in message news:op.xuco5eutc9evq2@nikita-pc...
On Fri, 20 Feb 2015 12:39:33 +0300, Tony Marston
tonymars...@hotmail.com
wrote:
I disagree. Exceptions were originally invented to solve the
semipredicate problem which only exists with procedural functions, not
object methods. Many OO purists would like exceptions to be thrown
everywhere, but this would present a huge BC break. If it were possible get
these functions to throw an exception ONLY when they are included in a try
... catch block then this would not break BC at all.
Tony, first of all - this still breaks BC, because exception is being
thrown in a place where it used not to be...
I disagree. The following function calls would not throw exceptions
fopen(...);
fwrite(...);
fclose(...);
while the following code would:
try {
fopen(...);
fwrite(...);
fclose(...);
} catch () {
}
When some function's result heavily depends on the context it makes said
function much harder to reason about. And creates mental overhead for those
who'll have to read the code with this function.
And again, if you need exceptions for fopen please consider using
SplFileObject.
For file usage, yes. But are there any other procedural functions without
an Spl* alternative which would benefit from this technique?
Expected failures should not raise exception. For example, IOs are expected
to fail (be network, filesystem etc), I would really not be in favor of
adding exceptions for similar cases. This is a normal control flow.
Then why do SplFileInfo::openFile and SplFileObject::__construct throw
exceptions if the file cannot be opened?
--
Tony Marston
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
Nikita Nefedov wrote in message news:op.xuco5eutc9evq2@nikita-pc...
On Fri, 20 Feb 2015 12:39:33 +0300, Tony Marston tonymars...@hotmail.com
wrote:
I disagree. Exceptions were originally invented to solve the
semipredicate problem which only exists with procedural functions, not
object methods. Many OO purists would like exceptions to be thrown
everywhere, but this would present a huge BC break. If it were possible
get these functions to throw an exception ONLY when they are included in
a try ... catch block then this would not break BC at all.
Tony, first of all - this still breaks BC, because exception is being
thrown in a place where it used not to be...
I disagree. The following function calls would not throw exceptions
fopen(...);
fwrite(...);
fclose(...);
while the following code would:
try {
fopen(...);
fwrite(...);
fclose(...);
} catch () {
}
When some function's result heavily depends on the context it makes said
function much harder to reason about. And creates mental overhead for
those who'll have to read the code with this function.
And again, if you need exceptions for fopen please consider using
SplFileObject.
For file usage, yes. But are there any other procedural functions without an
Spl* alternative which would benefit from this technique?
--
Tony Marston
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
On Feb 21, 2015 2:08 AM, Tony Marston tonymars...@hotmail.com wrote:
Nikita Nefedov wrote in message news:op.xuco5eutc9evq2@nikita-pc...
On Fri, 20 Feb 2015 12:39:33 +0300, Tony Marston tonymars...@hotmail.com
wrote:
I disagree. Exceptions were originally invented to solve the
semipredicate problem which only exists with procedural functions, not
object methods. Many OO purists would like exceptions to be thrown
everywhere, but this would present a huge BC break. If it were possible get
these functions to throw an exception ONLY when they are included in a try
... catch block then this would not break BC at all.
Tony, first of all - this still breaks BC, because exception is being
thrown in a place where it used not to be...
I disagree. The following function calls would not throw exceptions
fopen(...);
fwrite(...);
fclose(...);
while the following code would:
try {
fopen(...);
fwrite(...);
fclose(...);
} catch () {
}
When some function's result heavily depends on the context it makes said
function much harder to reason about. And creates mental overhead for those
who'll have to read the code with this function.
And again, if you need exceptions for fopen please consider using
SplFileObject.
For file usage, yes. But are there any other procedural functions without
an Spl* alternative which would benefit from this technique?
Expected failures should not raise exception. For example, IOs are expected
to fail (be network, filesystem etc), I would really not be in favor of
adding exceptions for similar cases. This is a normal control flow.
Re: [PHP-DEV] [RFC] Exceptions in the engine
On Fri, 20 Feb 2015 12:39:33 +0300, Tony Marston tonymars...@hotmail.com wrote: I disagree. Exceptions were originally invented to solve the semipredicate problem which only exists with procedural functions, not object methods. Many OO purists would like exceptions to be thrown everywhere, but this would present a huge BC break. If it were possible get these functions to throw an exception ONLY when they are included in a try ... catch block then this would not break BC at all. Tony, first of all - this still breaks BC, because exception is being thrown in a place where it used not to be... When some function's result heavily depends on the context it makes said function much harder to reason about. And creates mental overhead for those who'll have to read the code with this function. And again, if you need exceptions for fopen please consider using SplFileObject. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
Dmitry Stogov wrote in message
news:CA+9eiLu634OpuXVT8NnwZwitqc=s4g8ubbmj+cob4nmqcpx...@mail.gmail.com...
On Thu, Feb 19, 2015 at 12:03 PM, Tony Marston tonymars...@hotmail.com
wrote:
Rowan Collins wrote in message news:54e4fac2.7060...@gmail.com...
Tony Marston wrote on 18/02/2015 10:52:
Rowan Collins wrote in message news:54e32caa.5030...@gmail.com...
Tony Marston wrote on 17/02/2015 09:59:
Rowan Collins wrote in message news:54e1c993.1070...@gmail.com...
Tony Marston wrote on 16/02/2015 10:09:
This RFC only mentions errors with object methods, so what impact
would it have with procedural functions. For example, if
fopen('nonexistantfile.txt') fails the return value is FALSE and an
E_WARNING is generated, but it is difficult to trap the error
message (it
could be a permissions error, for example). Is there any plan to
convert
procedural functions to throw exceptions?
As Nikita already said:
This RFC is strictly about fatal and recoverable fatal errors.
Changing any
other error types to exceptions would be a significant
backwards-compatibility break.
That is why I suggested that those functions could be made to switch between
throwing an exception or not based on them being included within a try ...
catch block (or not)
So, no, since that's currently an E_WARNING, there is no current
plan
to change that case to an exception. If we were writing fopen() from
scratch now, it might be worth considering, but the BC implications
of
changing something from non-fatal to fatal are rather drastic.
Currently the only values returned by fopen(), fwrite() and fclose()
indicate either success or failure, but not the reason for any failure.
That has absolutely nothing to do with OO vs procedural code,
though.
I disagree. Exceptions were originally invented to solve the semipredicate
problem which only exists with procedural functions, not object methods.
Many OO purists would like exceptions to be thrown everywhere, but this
would present a huge BC break. If it were possible get these functions to
throw an exception ONLY when they are included in a try ... catch block then
this would not break BC at all.
--
Tony Marston
A procedural function could well have an error condition which
should be
fatal if unhandled, but can usefully be caught somewhere up the
stack,
which is basically what an exception is for. Any procedural function
which
currently issues an E_ERROR or E_RECOVERABLE_ERROR is a candidate to
be
converted under the current RFC.
Regards,
The reason that I mentioned this problem with fopen() - the
difficulty
with capturing the error message if it fails - is that it also exists
with
some other functions as well, so it would be nice to be able to put
the
function in a try . catch block so that any and every message
could be
made available. It is quite obvious that changing fopen() to use
exceptions
would be a major BC break for all exiting applications, so my
question is
this:
Would it be possible to tell the function if it were being called in
a
try ... catch bloc or not? If it were then throw an exception, if not
then
don't throw an exception. I realise that this might be tricky to
implement,
but if it could be it would allow the developer to choose whether
he/she
wanted to use exceptions or not instead of having the choice forced
upon
him/her.
Is this possible? Or am I just dreaming?
The point of exceptions is that they don't have to be caught in the
current scope. So is the below fopen() call in a try ... catch block
for
the purposes of that check, or not? If putting try { ... } around an
entire
application caused all calls to fopen(), in every library it used, to
stop
returning false, you'd have exactly the same BC issue as just changing
it
permanently.
function foo() {
try
{
$data = load_data();
}
catch ( ... ) { ... }
}
function load_data() {
$fh = fopen(...);
...
}
So no, I'm afraid it's probably not possible.
Could it be restricted to the current scope? In your example the call
to
fopen() exists in the load_data() function and is not in a try ...
catch
block within *that* function, so the fact that the call to load_data()
is
within a try ... catch block should be irrelevant as it is in a
different
scope.
If the exception is only thrown when the try - catch is in the same
scope, is there really much advantage to it being an exception? When
you're
that close to the code, sticking an if ( $fh === false ) { ... } around
it
really isn't that much different from catch(IOException $e) {
The advantage is that you can obtain the reason for the error. All that
happens with fopen() at the moment is that it returns FALSE which tells
you
that it has failed, but it does not tell you why. This is a classic
example
of the semipredicate problem for which exceptions were originally
designed.
The main advantage is the ability to catch FATAL errors that previously
leaded to script termination and 500
Re: [PHP-DEV] [RFC] Exceptions in the engine
Rowan Collins wrote in message news:54e4fac2.7060...@gmail.com...
Tony Marston wrote on 18/02/2015 10:52:
Rowan Collins wrote in message news:54e32caa.5030...@gmail.com...
Tony Marston wrote on 17/02/2015 09:59:
Rowan Collins wrote in message news:54e1c993.1070...@gmail.com...
Tony Marston wrote on 16/02/2015 10:09:
This RFC only mentions errors with object methods, so what impact
would it have with procedural functions. For example, if
fopen('nonexistantfile.txt') fails the return value is FALSE and an
E_WARNING is generated, but it is difficult to trap the error message
(it could be a permissions error, for example). Is there any plan to
convert procedural functions to throw exceptions?
As Nikita already said:
This RFC is strictly about fatal and recoverable fatal errors.
Changing any
other error types to exceptions would be a significant
backwards-compatibility break.
So, no, since that's currently an E_WARNING, there is no current plan
to change that case to an exception. If we were writing fopen() from
scratch now, it might be worth considering, but the BC implications of
changing something from non-fatal to fatal are rather drastic.
That has absolutely nothing to do with OO vs procedural code, though.
A procedural function could well have an error condition which should
be fatal if unhandled, but can usefully be caught somewhere up the
stack, which is basically what an exception is for. Any procedural
function which currently issues an E_ERROR or E_RECOVERABLE_ERROR is a
candidate to be converted under the current RFC.
Regards,
The reason that I mentioned this problem with fopen() - the difficulty
with capturing the error message if it fails - is that it also exists
with some other functions as well, so it would be nice to be able to
put the function in a try . catch block so that any and every
message could be made available. It is quite obvious that changing
fopen() to use exceptions would be a major BC break for all exiting
applications, so my question is this:
Would it be possible to tell the function if it were being called in a
try ... catch bloc or not? If it were then throw an exception, if not
then don't throw an exception. I realise that this might be tricky to
implement, but if it could be it would allow the developer to choose
whether he/she wanted to use exceptions or not instead of having the
choice forced upon him/her.
Is this possible? Or am I just dreaming?
The point of exceptions is that they don't have to be caught in the
current scope. So is the below fopen() call in a try ... catch block
for the purposes of that check, or not? If putting try { ... } around an
entire application caused all calls to fopen(), in every library it
used, to stop returning false, you'd have exactly the same BC issue as
just changing it permanently.
function foo() {
try
{
$data = load_data();
}
catch ( ... ) { ... }
}
function load_data() {
$fh = fopen(...);
...
}
So no, I'm afraid it's probably not possible.
Regards,
Could it be restricted to the current scope? In your example the call to
fopen() exists in the load_data() function and is not in a try ... catch
block within *that* function, so the fact that the call to load_data() is
within a try ... catch block should be irrelevant as it is in a different
scope.
If the exception is only thrown when the try - catch is in the same scope,
is there really much advantage to it being an exception? When you're that
close to the code, sticking an if ( $fh === false ) { ... } around it
really isn't that much different from catch(IOException $e) {
The advantage is that you can obtain the reason for the error. All that
happens with fopen() at the moment is that it returns FALSE which tells you
that it has failed, but it does not tell you why. This is a classic example
of the semipredicate problem for which exceptions were originally designed.
Having the problem be detectable in a higher scope is kind of the point of
exceptions.
So is the ability of catching an exception immediately it is thrown so that
you can obtain the error message. Having the ability to deal with an
exception at a higher level is only relevant if you don't deal with it
immediately, either by design or by accident.
--
Tony Marston
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
Nikita Nefedov wrote in message news:CALuY8tjUq70eLkV-MbDi-fEXZvWTFi82zCNmWr7tmvpiES9=p...@mail.gmail.com... On 18 Feb 2015 13:53, Tony Marston tonymars...@hotmail.com wrote: Could it be restricted to the current scope? In your example the call to fopen() exists in the load_data() function and is not in a try ... catch block within *that* function, so the fact that the call to load_data() is within a try ... catch block should be irrelevant as it is in a different scope. Hi Tony, This sounds very hacky. You could say that every piece of code is a hack with the only difference being that some hacks are ugly while others are beautiful. If you want exceptions with file/stream functions I suggest you to find some open library out there that can handle your user case or you can use SplFileObject. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
On 19 Feb 2015, at 12:54, Dmitry Stogov dmi...@zend.com wrote:
I think we may introduce the following hierarchy
abstarct class BaseException {
}
class Exception extends BaseException {
}
class EngineException extends BaseException {
}
the existing code that caught Exception is going to be unaffected.
New code may decide to catch engine exception in separate catch block
(using EngineException) or in single block (using BaseException)
If I remember it correctly, BaseException was used by some real code out there.
But we can use _BaseException instead
--
Alexey Zakhlestin
CTO at Grids.by/you
https://github.com/indeyets
PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: [PHP-DEV] [RFC] Exceptions in the engine
On Thu, Feb 19, 2015 at 12:03 PM, Tony Marston tonymars...@hotmail.com
wrote:
Rowan Collins wrote in message news:54e4fac2.7060...@gmail.com...
Tony Marston wrote on 18/02/2015 10:52:
Rowan Collins wrote in message news:54e32caa.5030...@gmail.com...
Tony Marston wrote on 17/02/2015 09:59:
Rowan Collins wrote in message news:54e1c993.1070...@gmail.com...
Tony Marston wrote on 16/02/2015 10:09:
This RFC only mentions errors with object methods, so what impact
would it have with procedural functions. For example, if
fopen('nonexistantfile.txt') fails the return value is FALSE and an
E_WARNING is generated, but it is difficult to trap the error message
(it
could be a permissions error, for example). Is there any plan to convert
procedural functions to throw exceptions?
As Nikita already said:
This RFC is strictly about fatal and recoverable fatal errors.
Changing any
other error types to exceptions would be a significant
backwards-compatibility break.
So, no, since that's currently an E_WARNING, there is no current plan
to change that case to an exception. If we were writing fopen() from
scratch now, it might be worth considering, but the BC implications of
changing something from non-fatal to fatal are rather drastic.
That has absolutely nothing to do with OO vs procedural code, though.
A procedural function could well have an error condition which should be
fatal if unhandled, but can usefully be caught somewhere up the stack,
which is basically what an exception is for. Any procedural function
which
currently issues an E_ERROR or E_RECOVERABLE_ERROR is a candidate to be
converted under the current RFC.
Regards,
The reason that I mentioned this problem with fopen() - the difficulty
with capturing the error message if it fails - is that it also exists with
some other functions as well, so it would be nice to be able to put the
function in a try . catch block so that any and every message could
be
made available. It is quite obvious that changing fopen() to use
exceptions
would be a major BC break for all exiting applications, so my question is
this:
Would it be possible to tell the function if it were being called in a
try ... catch bloc or not? If it were then throw an exception, if not then
don't throw an exception. I realise that this might be tricky to
implement,
but if it could be it would allow the developer to choose whether he/she
wanted to use exceptions or not instead of having the choice forced upon
him/her.
Is this possible? Or am I just dreaming?
The point of exceptions is that they don't have to be caught in the
current scope. So is the below fopen() call in a try ... catch block for
the purposes of that check, or not? If putting try { ... } around an entire
application caused all calls to fopen(), in every library it used, to stop
returning false, you'd have exactly the same BC issue as just changing it
permanently.
function foo() {
try
{
$data = load_data();
}
catch ( ... ) { ... }
}
function load_data() {
$fh = fopen(...);
...
}
So no, I'm afraid it's probably not possible.
Regards,
Could it be restricted to the current scope? In your example the call to
fopen() exists in the load_data() function and is not in a try ... catch
block within *that* function, so the fact that the call to load_data() is
within a try ... catch block should be irrelevant as it is in a different
scope.
If the exception is only thrown when the try - catch is in the same
scope, is there really much advantage to it being an exception? When you're
that close to the code, sticking an if ( $fh === false ) { ... } around it
really isn't that much different from catch(IOException $e) {
The advantage is that you can obtain the reason for the error. All that
happens with fopen() at the moment is that it returns FALSE which tells you
that it has failed, but it does not tell you why. This is a classic example
of the semipredicate problem for which exceptions were originally designed.
The main advantage is the ability to catch FATAL errors that previously
leaded to script termination and 500 response.
Thanks. Dmitry.
Having the problem be detectable in a higher scope is kind of the point
of exceptions.
So is the ability of catching an exception immediately it is thrown so
that you can obtain the error message. Having the ability to deal with an
exception at a higher level is only relevant if you don't deal with it
immediately, either by design or by accident.
--
Tony Marston
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
I am not familiar with the implementation details but from my perspective this would be a nice improvement. I have had a difficult time debugging PHP fatal errors over the years and I think this kind of change would help improve that. On Mon, Oct 6, 2014 at 4:53 PM, Nikita Popov nikita@gmail.com wrote: Hi internals! During the PHP 5.6 development cycle I have proposed an RFC [1] that suggested the use of exceptions instead of fatal errors in the engine. At the time the proposal was declined, because the change was judged too intrusive for a minor version. As such I'm re-proposing this RFC for inclusion in PHP 7: https://wiki.php.net/rfc/engine_exceptions_for_php7 The RFC text is essentially the same as previously, with the primary difference being that parse errors are now converted to exceptions as well. This was previously not possible due to limitations in the compiler design. Thanks, Nikita [1]: https://wiki.php.net/rfc/engine_exceptions -- Connect with me on *http://twitter.com/jwage* http://twitter.com/jwage
Re: [PHP-DEV] [RFC] Exceptions in the engine
On 18 Feb 2015 13:53, Tony Marston tonymars...@hotmail.com wrote: Could it be restricted to the current scope? In your example the call to fopen() exists in the load_data() function and is not in a try ... catch block within *that* function, so the fact that the call to load_data() is within a try ... catch block should be irrelevant as it is in a different scope. Hi Tony, This sounds very hacky. If you want exceptions with file/stream functions I suggest you to find some open library out there that can handle your user case or you can use SplFileObject.
Re: [PHP-DEV] [RFC] Exceptions in the engine
Rowan Collins wrote in message news:54e32caa.5030...@gmail.com...
Tony Marston wrote on 17/02/2015 09:59:
Rowan Collins wrote in message news:54e1c993.1070...@gmail.com...
Tony Marston wrote on 16/02/2015 10:09:
This RFC only mentions errors with object methods, so what impact would
it have with procedural functions. For example, if
fopen('nonexistantfile.txt') fails the return value is FALSE and an
E_WARNING is generated, but it is difficult to trap the error message
(it could be a permissions error, for example). Is there any plan to
convert procedural functions to throw exceptions?
As Nikita already said:
This RFC is strictly about fatal and recoverable fatal errors. Changing
any
other error types to exceptions would be a significant
backwards-compatibility break.
So, no, since that's currently an E_WARNING, there is no current plan to
change that case to an exception. If we were writing fopen() from
scratch now, it might be worth considering, but the BC implications of
changing something from non-fatal to fatal are rather drastic.
That has absolutely nothing to do with OO vs procedural code, though. A
procedural function could well have an error condition which should be
fatal if unhandled, but can usefully be caught somewhere up the stack,
which is basically what an exception is for. Any procedural function
which currently issues an E_ERROR or E_RECOVERABLE_ERROR is a candidate
to be converted under the current RFC.
Regards,
The reason that I mentioned this problem with fopen() - the difficulty
with capturing the error message if it fails - is that it also exists
with some other functions as well, so it would be nice to be able to put
the function in a try . catch block so that any and every message
could be made available. It is quite obvious that changing fopen() to use
exceptions would be a major BC break for all exiting applications, so my
question is this:
Would it be possible to tell the function if it were being called in a
try ... catch bloc or not? If it were then throw an exception, if not
then don't throw an exception. I realise that this might be tricky to
implement, but if it could be it would allow the developer to choose
whether he/she wanted to use exceptions or not instead of having the
choice forced upon him/her.
Is this possible? Or am I just dreaming?
The point of exceptions is that they don't have to be caught in the current
scope. So is the below fopen() call in a try ... catch block for the
purposes of that check, or not? If putting try { ... } around an entire
application caused all calls to fopen(), in every library it used, to stop
returning false, you'd have exactly the same BC issue as just changing it
permanently.
function foo() {
try
{
$data = load_data();
}
catch ( ... ) { ... }
}
function load_data() {
$fh = fopen(...);
...
}
So no, I'm afraid it's probably not possible.
Regards,
Could it be restricted to the current scope? In your example the call to
fopen() exists in the load_data() function and is not in a try ... catch
block within *that* function, so the fact that the call to load_data() is
within a try ... catch block should be irrelevant as it is in a different
scope.
--
Tony Marston
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
Tony Marston wrote on 18/02/2015 10:52:
Rowan Collins wrote in message news:54e32caa.5030...@gmail.com...
Tony Marston wrote on 17/02/2015 09:59:
Rowan Collins wrote in message news:54e1c993.1070...@gmail.com...
Tony Marston wrote on 16/02/2015 10:09:
This RFC only mentions errors with object methods, so what impact
would it have with procedural functions. For example, if
fopen('nonexistantfile.txt') fails the return value is FALSE and
an E_WARNING is generated, but it is difficult to trap the error
message (it could be a permissions error, for example). Is there
any plan to convert procedural functions to throw exceptions?
As Nikita already said:
This RFC is strictly about fatal and recoverable fatal errors.
Changing any
other error types to exceptions would be a significant
backwards-compatibility break.
So, no, since that's currently an E_WARNING, there is no current
plan to change that case to an exception. If we were writing
fopen() from scratch now, it might be worth considering, but the BC
implications of changing something from non-fatal to fatal are
rather drastic.
That has absolutely nothing to do with OO vs procedural code,
though. A procedural function could well have an error condition
which should be fatal if unhandled, but can usefully be caught
somewhere up the stack, which is basically what an exception is
for. Any procedural function which currently issues an E_ERROR or
E_RECOVERABLE_ERROR is a candidate to be converted under the
current RFC.
Regards,
The reason that I mentioned this problem with fopen() - the
difficulty with capturing the error message if it fails - is that it
also exists with some other functions as well, so it would be nice
to be able to put the function in a try . catch block so that
any and every message could be made available. It is quite obvious
that changing fopen() to use exceptions would be a major BC break
for all exiting applications, so my question is this:
Would it be possible to tell the function if it were being called in
a try ... catch bloc or not? If it were then throw an exception, if
not then don't throw an exception. I realise that this might be
tricky to implement, but if it could be it would allow the developer
to choose whether he/she wanted to use exceptions or not instead of
having the choice forced upon him/her.
Is this possible? Or am I just dreaming?
The point of exceptions is that they don't have to be caught in the
current scope. So is the below fopen() call in a try ... catch
block for the purposes of that check, or not? If putting try { ... }
around an entire application caused all calls to fopen(), in every
library it used, to stop returning false, you'd have exactly the same
BC issue as just changing it permanently.
function foo() {
try
{
$data = load_data();
}
catch ( ... ) { ... }
}
function load_data() {
$fh = fopen(...);
...
}
So no, I'm afraid it's probably not possible.
Regards,
Could it be restricted to the current scope? In your example the call
to fopen() exists in the load_data() function and is not in a try ...
catch block within *that* function, so the fact that the call to
load_data() is within a try ... catch block should be irrelevant as it
is in a different scope.
If the exception is only thrown when the try - catch is in the same
scope, is there really much advantage to it being an exception? When
you're that close to the code, sticking an if ( $fh === false ) { ... }
around it really isn't that much different from catch(IOException $e) {
... }.
Having the problem be detectable in a higher scope is kind of the point
of exceptions.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
Tony Marston wrote on 17/02/2015 09:59:
Rowan Collins wrote in message news:54e1c993.1070...@gmail.com...
Tony Marston wrote on 16/02/2015 10:09:
This RFC only mentions errors with object methods, so what impact
would it have with procedural functions. For example, if
fopen('nonexistantfile.txt') fails the return value is FALSE and an
E_WARNING is generated, but it is difficult to trap the error
message (it could be a permissions error, for example). Is there any
plan to convert procedural functions to throw exceptions?
As Nikita already said:
This RFC is strictly about fatal and recoverable fatal errors.
Changing any
other error types to exceptions would be a significant
backwards-compatibility break.
So, no, since that's currently an E_WARNING, there is no current plan
to change that case to an exception. If we were writing fopen() from
scratch now, it might be worth considering, but the BC implications
of changing something from non-fatal to fatal are rather drastic.
That has absolutely nothing to do with OO vs procedural code, though.
A procedural function could well have an error condition which should
be fatal if unhandled, but can usefully be caught somewhere up the
stack, which is basically what an exception is for. Any procedural
function which currently issues an E_ERROR or E_RECOVERABLE_ERROR is
a candidate to be converted under the current RFC.
Regards,
The reason that I mentioned this problem with fopen() - the difficulty
with capturing the error message if it fails - is that it also exists
with some other functions as well, so it would be nice to be able to
put the function in a try . catch block so that any and every
message could be made available. It is quite obvious that changing
fopen() to use exceptions would be a major BC break for all exiting
applications, so my question is this:
Would it be possible to tell the function if it were being called in a
try ... catch bloc or not? If it were then throw an exception, if not
then don't throw an exception. I realise that this might be tricky to
implement, but if it could be it would allow the developer to choose
whether he/she wanted to use exceptions or not instead of having the
choice forced upon him/her.
Is this possible? Or am I just dreaming?
The point of exceptions is that they don't have to be caught in the
current scope. So is the below fopen() call in a try ... catch block
for the purposes of that check, or not? If putting try { ... } around an
entire application caused all calls to fopen(), in every library it
used, to stop returning false, you'd have exactly the same BC issue as
just changing it permanently.
function foo() {
try
{
$data = load_data();
}
catch ( ... ) { ... }
}
function load_data() {
$fh = fopen(...);
...
}
So no, I'm afraid it's probably not possible.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
Am 14.02.2015 um 00:25 schrieb Nikita Popov nikita@gmail.com: On Mon, Oct 6, 2014 at 11:53 PM, Nikita Popov nikita@gmail.com wrote: Hi internals! During the PHP 5.6 development cycle I have proposed an RFC [1] that suggested the use of exceptions instead of fatal errors in the engine. At the time the proposal was declined, because the change was judged too intrusive for a minor version. As such I'm re-proposing this RFC for inclusion in PHP 7: https://wiki.php.net/rfc/engine_exceptions_for_php7 The RFC text is essentially the same as previously, with the primary difference being that parse errors are now converted to exceptions as well. This was previously not possible due to limitations in the compiler design. Thanks, Nikita [1]: https://wiki.php.net/rfc/engine_exceptions Feature freeze is not so far away now, so I'd like to bring this RFC up again and proceed to voting shortly. There are two primary open questions: * Subclassing: Should there be more specific subclasses of EngineException for particular errors? * Superclassing: Should EngineException inherit from Exception (and as such be subject to catch(Exception)) or should we introduce some kind of special super-class that is not caught by default (like Catchable/Throwable)? I don't think we can implement a high-quality subclassing scheme in a timeframe for PHP 7, as such I would suggest to postpone this (if we actually want to do it) to a later point in time. We can introduce subclasses without BC issues in a minor version. The question of whether EngineException should inherit from Exception is something we do have to consider now. Personally I prefer not introducing any special exception types that aren't caught by default. I think that would only make sense for errors that could occur literally everywhere (like memory limit or timeout), but these are not handled by this RFC for technical reasons. If someone has a strong opinion on this, I might make it a voting option. Commentary on these, and also any other relevant points is very welcome! Thanks, Nikita PS: The patch attached to the RFC is very outdated. I plan to only update it to current master once the RFC passes (if it does), as I already had to practically rewrite it a few times. Hey, For subclassing I totally agree that we should postpone this (if we want this at all). I think EngineException should inherit from Exception. You usually only catch Exception in catch-all handlers to display, log etc. the backtraces. In all these cases, you're very likely to want to catch the EngineException too, without a second catch block where the catch body is duplicated. I can't really think of a catch-all block where you'd explicitly don't want to handle EngineException. And if it'd really be the case, you still can do an instanceof check and rethrow if needed... Thanks, Bob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
Rowan Collins wrote in message news:54e1c993.1070...@gmail.com...
Tony Marston wrote on 16/02/2015 10:09:
This RFC only mentions errors with object methods, so what impact would
it have with procedural functions. For example, if
fopen('nonexistantfile.txt') fails the return value is FALSE and an
E_WARNING is generated, but it is difficult to trap the error message (it
could be a permissions error, for example). Is there any plan to convert
procedural functions to throw exceptions?
As Nikita already said:
This RFC is strictly about fatal and recoverable fatal errors. Changing
any
other error types to exceptions would be a significant
backwards-compatibility break.
So, no, since that's currently an E_WARNING, there is no current plan to
change that case to an exception. If we were writing fopen() from scratch
now, it might be worth considering, but the BC implications of changing
something from non-fatal to fatal are rather drastic.
That has absolutely nothing to do with OO vs procedural code, though. A
procedural function could well have an error condition which should be
fatal if unhandled, but can usefully be caught somewhere up the stack,
which is basically what an exception is for. Any procedural function which
currently issues an E_ERROR or E_RECOVERABLE_ERROR is a candidate to be
converted under the current RFC.
Regards,
The reason that I mentioned this problem with fopen() - the difficulty with
capturing the error message if it fails - is that it also exists with some
other functions as well, so it would be nice to be able to put the function
in a try . catch block so that any and every message could be made
available. It is quite obvious that changing fopen() to use exceptions would
be a major BC break for all exiting applications, so my question is this:
Would it be possible to tell the function if it were being called in a try
... catch bloc or not? If it were then throw an exception, if not then don't
throw an exception. I realise that this might be tricky to implement, but if
it could be it would allow the developer to choose whether he/she wanted to
use exceptions or not instead of having the choice forced upon him/her.
Is this possible? Or am I just dreaming?
--
Tony Marston
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
Am 17.02.2015 um 11:21 schrieb Benjamin Eberlei kont...@beberlei.de: On Tue, Feb 17, 2015 at 11:14 AM, Bob Weinand bobw...@hotmail.com mailto:bobw...@hotmail.com wrote: Am 14.02.2015 um 00:25 schrieb Nikita Popov nikita@gmail.com mailto:nikita@gmail.com: On Mon, Oct 6, 2014 at 11:53 PM, Nikita Popov nikita@gmail.com mailto:nikita@gmail.com wrote: Hi internals! During the PHP 5.6 development cycle I have proposed an RFC [1] that suggested the use of exceptions instead of fatal errors in the engine. At the time the proposal was declined, because the change was judged too intrusive for a minor version. As such I'm re-proposing this RFC for inclusion in PHP 7: https://wiki.php.net/rfc/engine_exceptions_for_php7 https://wiki.php.net/rfc/engine_exceptions_for_php7 The RFC text is essentially the same as previously, with the primary difference being that parse errors are now converted to exceptions as well. This was previously not possible due to limitations in the compiler design. Thanks, Nikita [1]: https://wiki.php.net/rfc/engine_exceptions https://wiki.php.net/rfc/engine_exceptions Feature freeze is not so far away now, so I'd like to bring this RFC up again and proceed to voting shortly. There are two primary open questions: * Subclassing: Should there be more specific subclasses of EngineException for particular errors? * Superclassing: Should EngineException inherit from Exception (and as such be subject to catch(Exception)) or should we introduce some kind of special super-class that is not caught by default (like Catchable/Throwable)? I don't think we can implement a high-quality subclassing scheme in a timeframe for PHP 7, as such I would suggest to postpone this (if we actually want to do it) to a later point in time. We can introduce subclasses without BC issues in a minor version. The question of whether EngineException should inherit from Exception is something we do have to consider now. Personally I prefer not introducing any special exception types that aren't caught by default. I think that would only make sense for errors that could occur literally everywhere (like memory limit or timeout), but these are not handled by this RFC for technical reasons. If someone has a strong opinion on this, I might make it a voting option. Commentary on these, and also any other relevant points is very welcome! Thanks, Nikita PS: The patch attached to the RFC is very outdated. I plan to only update it to current master once the RFC passes (if it does), as I already had to practically rewrite it a few times. Hey, For subclassing I totally agree that we should postpone this (if we want this at all). I think EngineException should inherit from Exception. You usually only catch Exception in catch-all handlers to display, log etc. the backtraces. In all these cases, you're very likely to want to catch the EngineException too, without a second catch block where the catch body is duplicated. I can't really think of a catch-all block where you'd explicitly don't want to handle EngineException. And if it'd really be the case, you still can do an instanceof check and rethrow if needed... I think that would be a huge BC break. I see a lot of code just catching \Exception at various customers and opensource projects. EngineException should not be a child of Exception. Thanks, Bob No, it isn't a BC break. It would only affect broken things, which generate fatals as of now. Working applications are not affected and that way it does not break BC. So, I don't see any harm here in superclassing EngineException. Bob
Re: [PHP-DEV] [RFC] Exceptions in the engine
On Tue, Feb 17, 2015 at 11:14 AM, Bob Weinand bobw...@hotmail.com wrote: Am 14.02.2015 um 00:25 schrieb Nikita Popov nikita@gmail.com: On Mon, Oct 6, 2014 at 11:53 PM, Nikita Popov nikita@gmail.com wrote: Hi internals! During the PHP 5.6 development cycle I have proposed an RFC [1] that suggested the use of exceptions instead of fatal errors in the engine. At the time the proposal was declined, because the change was judged too intrusive for a minor version. As such I'm re-proposing this RFC for inclusion in PHP 7: https://wiki.php.net/rfc/engine_exceptions_for_php7 The RFC text is essentially the same as previously, with the primary difference being that parse errors are now converted to exceptions as well. This was previously not possible due to limitations in the compiler design. Thanks, Nikita [1]: https://wiki.php.net/rfc/engine_exceptions Feature freeze is not so far away now, so I'd like to bring this RFC up again and proceed to voting shortly. There are two primary open questions: * Subclassing: Should there be more specific subclasses of EngineException for particular errors? * Superclassing: Should EngineException inherit from Exception (and as such be subject to catch(Exception)) or should we introduce some kind of special super-class that is not caught by default (like Catchable/Throwable)? I don't think we can implement a high-quality subclassing scheme in a timeframe for PHP 7, as such I would suggest to postpone this (if we actually want to do it) to a later point in time. We can introduce subclasses without BC issues in a minor version. The question of whether EngineException should inherit from Exception is something we do have to consider now. Personally I prefer not introducing any special exception types that aren't caught by default. I think that would only make sense for errors that could occur literally everywhere (like memory limit or timeout), but these are not handled by this RFC for technical reasons. If someone has a strong opinion on this, I might make it a voting option. Commentary on these, and also any other relevant points is very welcome! Thanks, Nikita PS: The patch attached to the RFC is very outdated. I plan to only update it to current master once the RFC passes (if it does), as I already had to practically rewrite it a few times. Hey, For subclassing I totally agree that we should postpone this (if we want this at all). I think EngineException should inherit from Exception. You usually only catch Exception in catch-all handlers to display, log etc. the backtraces. In all these cases, you're very likely to want to catch the EngineException too, without a second catch block where the catch body is duplicated. I can't really think of a catch-all block where you'd explicitly don't want to handle EngineException. And if it'd really be the case, you still can do an instanceof check and rethrow if needed... I think that would be a huge BC break. I see a lot of code just catching \Exception at various customers and opensource projects. EngineException should not be a child of Exception. Thanks, Bob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
Tony Marston wrote on 16/02/2015 10:09:
This RFC only mentions errors with object methods, so what impact
would it have with procedural functions. For example, if
fopen('nonexistantfile.txt') fails the return value is FALSE and an
E_WARNING is generated, but it is difficult to trap the error message
(it could be a permissions error, for example). Is there any plan to
convert procedural functions to throw exceptions?
As Nikita already said:
This RFC is strictly about fatal and recoverable fatal errors. Changing any
other error types to exceptions would be a significant
backwards-compatibility break.
So, no, since that's currently an E_WARNING, there is no current plan to
change that case to an exception. If we were writing fopen() from
scratch now, it might be worth considering, but the BC implications of
changing something from non-fatal to fatal are rather drastic.
That has absolutely nothing to do with OO vs procedural code, though. A
procedural function could well have an error condition which should be
fatal if unhandled, but can usefully be caught somewhere up the stack,
which is basically what an exception is for. Any procedural function
which currently issues an E_ERROR or E_RECOVERABLE_ERROR is a candidate
to be converted under the current RFC.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
Rowan Collins wrote in message news:54e12349.7070...@gmail.com...
On 14/02/2015 00:09, Yasuo Ohgaki wrote:
Hi Nikita,
On Tue, Oct 7, 2014 at 6:53 AM, Nikita Popov nikita@gmail.com
wrote:
As such I'm re-proposing this RFC for inclusion in PHP 7:
https://wiki.php.net/rfc/engine_exceptions_for_php7
The RFC text is essentially the same as previously, with the primary
difference being that parse errors are now converted to exceptions as
well.
This was previously not possible due to limitations in the compiler
design.
Are E_WARNING, etc future scope?
I briefly looked the patch. It seems it covers only engine errors.
I suppose it's the scope of this RFC, though.
If API is made adoptable to modules for E_WARNING, etc, it would be
great.
Much though I'd love a more OO-approach to warnings, exceptions are not an
appropriate mechanism for that.
A rule of thumb I rather like is that you should only throw an exception in
a case where your best alternative, if it is not handled, is to call die().
Clearly, E_ERROR meets this standard, and E_WARNING does not.
There has been much talk previously that exceptions are great because they
include full backtraces, but there's no reason a new type of warning
object couldn't also include those, while retaining the key characteristic
of the default behaviour being to carry on with some fallback value (an
empty loop, a null variable, etc) rather than to die('Uncaught Warning
Exception!').
Regards,
This RFC only mentions errors with object methods, so what impact would it
have with procedural functions. For example, if fopen('nonexistantfile.txt')
fails the return value is FALSE and an E_WARNING is generated, but it is
difficult to trap the error message (it could be a permissions error, for
example). Is there any plan to convert procedural functions to throw
exceptions?
--
Tony Marston
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
On 14/02/2015 00:09, Yasuo Ohgaki wrote:
Hi Nikita,
On Tue, Oct 7, 2014 at 6:53 AM, Nikita Popov nikita@gmail.com wrote:
As such I'm re-proposing this RFC for inclusion in PHP 7:
https://wiki.php.net/rfc/engine_exceptions_for_php7
The RFC text is essentially the same as previously, with the primary
difference being that parse errors are now converted to exceptions as well.
This was previously not possible due to limitations in the compiler design.
Are E_WARNING, etc future scope?
I briefly looked the patch. It seems it covers only engine errors.
I suppose it's the scope of this RFC, though.
If API is made adoptable to modules for E_WARNING, etc, it would be
great.
Much though I'd love a more OO-approach to warnings, exceptions are not
an appropriate mechanism for that.
A rule of thumb I rather like is that you should only throw an exception
in a case where your best alternative, if it is not handled, is to call
die(). Clearly, E_ERROR meets this standard, and E_WARNING does not.
There has been much talk previously that exceptions are great because
they include full backtraces, but there's no reason a new type of
warning object couldn't also include those, while retaining the key
characteristic of the default behaviour being to carry on with some
fallback value (an empty loop, a null variable, etc) rather than to
die('Uncaught Warning Exception!').
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
Hi Nikita, On Tue, Oct 7, 2014 at 6:53 AM, Nikita Popov nikita@gmail.com wrote: As such I'm re-proposing this RFC for inclusion in PHP 7: https://wiki.php.net/rfc/engine_exceptions_for_php7 The RFC text is essentially the same as previously, with the primary difference being that parse errors are now converted to exceptions as well. This was previously not possible due to limitations in the compiler design. Are E_WARNING, etc future scope? I briefly looked the patch. It seems it covers only engine errors. I suppose it's the scope of this RFC, though. If API is made adoptable to modules for E_WARNING, etc, it would be great. Anyway, +1 Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [RFC] Exceptions in the engine
On Sat, Feb 14, 2015 at 1:09 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Nikita, On Tue, Oct 7, 2014 at 6:53 AM, Nikita Popov nikita@gmail.com wrote: As such I'm re-proposing this RFC for inclusion in PHP 7: https://wiki.php.net/rfc/engine_exceptions_for_php7 The RFC text is essentially the same as previously, with the primary difference being that parse errors are now converted to exceptions as well. This was previously not possible due to limitations in the compiler design. Are E_WARNING, etc future scope? I briefly looked the patch. It seems it covers only engine errors. I suppose it's the scope of this RFC, though. If API is made adoptable to modules for E_WARNING, etc, it would be great. This RFC is strictly about fatal and recoverable fatal errors. Changing any other error types to exceptions would be a significant backwards-compatibility break. Nikita Anyway, +1 Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [RFC] Exceptions in the engine
On Tue, Oct 7, 2014 at 1:07 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! As such I'm re-proposing this RFC for inclusion in PHP 7: https://wiki.php.net/rfc/engine_exceptions_for_php7 The RFC text is essentially the same as previously, with the primary difference being that parse errors are now converted to exceptions as well. This was previously not possible due to limitations in the compiler design. I like this. Fatal errors and warnings were for a long time in different leagues, and the need to handle them better produced E_RECOVERABLE_ERROR which is a weird creature - like exception but not quite. I think PHP 7 is a good time to move to exceptions for real errors (as opposed to informational messages like E_WARNING). The only issue I think we need to discuss is catch(Exception $e). Now it would catch much more than before, if we do no changes. Should we allow it or should be have hierarchy that separates user exceptions and engine exceptions, and have catch(Exception) catch only the former. There is precedent in other languages for having exceptions that are not usually caught. Java has a Throwable interface, which is implemented by Exceptions and Errors, where the latter are usually not supposed to be caught. Python has a BaseException, which is extended by Exception and SystemExit, GeneratorExit and KeyboardInterrupt, where the latter three are not usually supposed to be caught. I think that the decision whether or not we wish to introduce something like this mainly depends on how we intend these EngineExceptions to be used. If they are only supposed to be caught by top-level code to enable graceful error handling (in particular for long running code) then it probably makes sense to keep them outside the main exception hierarchy. If on the other hand it's considered okay to catch them during normal program execution, they should be normal exceptions. However, I see in the RFC it does not remove all the errors. I think we need to strive for having all the non-core errors except for out of memory and timeout be converted. Are there ones that are problematic to convert or it is just the question of time/effort? There are a number of E_ERRORs that we cannot feasibly convert to exceptions. I've analyzed this for the previous discussion and likely the numbers are still about right: http://markmail.org/message/gfdczr6zpgzynid4 So a conservative estimate is that we can turn 85% of the E_ERROR occurrences into exceptions. (This doesn't tell us anything about the percentage of actually thrown errors though.) And yes, it's also a question of time/effort. The hard part usually isn't converting to exceptions, but updating all the tests that fail because of it. I'd like to have good exception coverage by the time PHP 7 gets released, but would prefer to do the porting incrementally (these huge patches get stale very fast). Nikita
Re: [PHP-DEV] [RFC] Exceptions in the engine
Looking at the list of fatal errors Nikita classified as not suitable for converting to exceptions, I'd like to take exception : ) with two of them: I would love to be able to catch, at toplevel. with an error handler or otherwise, both the memory limits exceeded and time limit exceeded cases. These two safeguards, by themselves, are not instabilities, right? The limits could be set a bit higher and everything would continue normally, right? What I would like to see, is that I can configure an extra allowance for both of these limits, in php.ini - if that extra allowance is configured, and the normal limit is reached, generate a recoverable / catchable error and/or exception, and extend the respective limit (once) by the extra allowance. So, in practise, I would allow 2 more seconds, and 10 MB more memory, for use in a global handler that gives nicer error message, backtrace, non-white-http-500-response, or similar reaction. best regards Patrick
Re: [PHP-DEV] [RFC] Exceptions in the engine
On 10 Oct 2014, at 13:31, Patrick Schaaf b...@bof.de wrote: I would love to be able to catch, at toplevel. with an error handler or otherwise, both the memory limits exceeded and time limit exceeded cases. These two safeguards, by themselves, are not instabilities, right? The limits could be set a bit higher and everything would continue normally, right? Both are problematic. There’s no *technical* reason to prevent catching the exceeding of the time limit… but that means you can circumvent the time limit. That’s bad. Perhaps you could catch it and have a short window to output an error and die, though? Memory limit catching *would* cause instability, though. That’s an error thrown during memory allocation. Things will break horribly if it just returns NULL and carries on, because let’s be realistic here, an awful lot of code doesn’t check for NULL return values. It’ll lead to a segfault. PHP must bail out immediately when this happens to prevent segfaulting. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
Stas wrote:
The only issue I think we need to discuss is catch(Exception $e). Now it
would catch much more than before, if we do no changes.
It's not clear why would that be an issue - can you specify what the
problem would be?
Also, if we changed `catch(Exception $e)` to not catch all exceptions,
than we would need to have another way of specifying that a catch
block should catch all exceptions. Which would involve either making
\Exception extend another even 'baser' Exception, or a hack to the
syntax e.g. something like:
catch($e) {
// Catch without Exception type catches all exceptions
// and confuses people.
}
cheers
Dan
Ack
On 7 October 2014 00:07, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
As such I'm re-proposing this RFC for inclusion in PHP 7:
https://wiki.php.net/rfc/engine_exceptions_for_php7
The RFC text is essentially the same as previously, with the primary
difference being that parse errors are now converted to exceptions as well.
This was previously not possible due to limitations in the compiler design.
I like this. Fatal errors and warnings were for a long time in different
leagues, and the need to handle them better produced E_RECOVERABLE_ERROR
which is a weird creature - like exception but not quite. I think PHP 7
is a good time to move to exceptions for real errors (as opposed to
informational messages like E_WARNING).
The only issue I think we need to discuss is catch(Exception $e). Now it
would catch much more than before, if we do no changes. Should we allow
it or should be have hierarchy that separates user exceptions and engine
exceptions, and have catch(Exception) catch only the former.
However, I see in the RFC it does not remove all the errors. I think we
need to strive for having all the non-core errors except for out of
memory and timeout be converted. Are there ones that are problematic to
convert or it is just the question of time/effort?
About the long error message - I usually wouldn't recommend that but
maybe here is a good place for an ini setting, saying if we really want
to display the stack trace for uncaught exceptions? In many production
systems, wasting time to collect and then print the backtrace may not be
needed, and one-point message is enough. Many tools already have such
option (xdebug included) so maybe if we move to exceptions core may have
something like that too?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
On Tue, Oct 7, 2014 at 10:55 AM, Dan Ackroyd dan...@basereality.com wrote:
Stas wrote:
The only issue I think we need to discuss is catch(Exception $e). Now it
would catch much more than before, if we do no changes.
It's not clear why would that be an issue - can you specify what the
problem would be?
Also, if we changed `catch(Exception $e)` to not catch all exceptions,
than we would need to have another way of specifying that a catch
block should catch all exceptions. Which would involve either making
\Exception extend another even 'baser' Exception, or a hack to the
syntax e.g. something like:
catch($e) {
// Catch without Exception type catches all exceptions
// and confuses people.
}
we discussed this before on the mailing list, the problem would be that
currently the fatal errors will stop the execution and even recoverable
fatals for most people (when they don't have a global error handler defined
to handle it) and theoretically it is possible that some code exists out
there with Pokemon Exception Handling (
http://c2.com/cgi/wiki?PokemonExceptionHandling) where the code would
continue the execution and probably does some logically faulty operation
which previously was only prevented by the fatal error stopping the code.
this indeed assumes that the user already follow bad coding practices(Catch
them all) and code with (potential) fatal errors so there were a
disagreement if we could afford this BC or not.
Personally I think that it would be fine for a major version.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
RE: [PHP-DEV] [RFC] Exceptions in the engine
From: Dan Ackroyd [mailto:dan...@basereality.com] ,Sent: Tuesday, October 07,
2014 10:55 AM
Stas wrote:
The only issue I think we need to discuss is catch(Exception $e). Now it
would catch much more than before, if we do no changes.
It's not clear why would that be an issue - can you specify what the
problem would be?
Also, if we changed `catch(Exception $e)` to not catch all exceptions,
than we would need to have another way of specifying that a catch
block should catch all exceptions. Which would involve either making
\Exception extend another even 'baser' Exception, or a hack to the
syntax e.g. something like:
catch($e) {
// Catch without Exception type catches all exceptions
// and confuses people.
}
cheers
Dan
Ack
We could make EngineException to be parent of the base Exception class.
And, if it is technically possible, it must be forbidden to extend
EngineException directly in userland.
This is just an idea. It would be a little bit strange if Exception is
not the base exception class ;) but it makes sense, because EngineException
is an exception of all other exceptions ^^
Christian
Re: [PHP-DEV] [RFC] Exceptions in the engine
Hi Nikita, I very like the idea. Actually, it's a long time desired php feature that many big php users miss. They don't like to show 500 response in any case. Also +1 for removing ability of silent E_RECOVERABLE_ERROR bypass :) I think that few things may be improved 1) I'm not sure if cacth(Exception $e) should catch engine and parser exceptions. May be it's better to introduce interface or common parent class Catchable and then make Exception, EngineException and ParseException implement it. In case user would like to catch all the error at once they will able to use catch(Catchable $e), but cacth(Exception $e) would be 100% compatible. 2) I also think it's not a big problem to keep compatible error messages for uncaught EngineException and ParseException. I'm not sure if that Uncaught EngineException: really need. Thanks. Dmitry. On Tue, Oct 7, 2014 at 1:53 AM, Nikita Popov nikita@gmail.com wrote: Hi internals! During the PHP 5.6 development cycle I have proposed an RFC [1] that suggested the use of exceptions instead of fatal errors in the engine. At the time the proposal was declined, because the change was judged too intrusive for a minor version. As such I'm re-proposing this RFC for inclusion in PHP 7: https://wiki.php.net/rfc/engine_exceptions_for_php7 The RFC text is essentially the same as previously, with the primary difference being that parse errors are now converted to exceptions as well. This was previously not possible due to limitations in the compiler design. Thanks, Nikita [1]: https://wiki.php.net/rfc/engine_exceptions
Re: [PHP-DEV] [RFC] Exceptions in the engine
On Tue, Oct 7, 2014 at 11:51 AM, Christian Stoller stol...@leonex.de
wrote:
From: Dan Ackroyd [mailto:dan...@basereality.com] ,Sent: Tuesday, October
07, 2014 10:55 AM
Stas wrote:
The only issue I think we need to discuss is catch(Exception $e). Now it
would catch much more than before, if we do no changes.
It's not clear why would that be an issue - can you specify what the
problem would be?
Also, if we changed `catch(Exception $e)` to not catch all exceptions,
than we would need to have another way of specifying that a catch
block should catch all exceptions. Which would involve either making
\Exception extend another even 'baser' Exception, or a hack to the
syntax e.g. something like:
catch($e) {
// Catch without Exception type catches all exceptions
// and confuses people.
}
cheers
Dan
Ack
We could make EngineException to be parent of the base Exception class.
And, if it is technically possible, it must be forbidden to extend
EngineException directly in userland.
This is just an idea. It would be a little bit strange if Exception is
not the base exception class ;) but it makes sense, because EngineException
is an exception of all other exceptions ^^
Christian
yes, this was also suggested before, but that will be also a BC break for
those people already using the name of the new parent class (
https://github.com/search?l=phpq=EngineExceptiontype=Codeutf8=%E2%9C%93
for example).
which can be still an ok decision, I'm just stating/repeating the pro/cons
as this was all discussed before.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [RFC] Exceptions in the engine
On 06.10.2014 23:53, Nikita Popov wrote: Hi internals! During the PHP 5.6 development cycle I have proposed an RFC [1] that suggested the use of exceptions instead of fatal errors in the engine. At the time the proposal was declined, because the change was judged too intrusive for a minor version. As such I'm re-proposing this RFC for inclusion in PHP 7: https://wiki.php.net/rfc/engine_exceptions_for_php7 ++ I very much like the change and have proposed something similar before. A major version change is the best time to do it and it will be long after php7 to see another one. This would enable us to cleanup much weird userland code. Just let's make sure to get it right this time. -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: l...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] Exceptions in the engine
Lars Strojny wrote (on 06/10/2014): Hi Nikita, On 06 Oct 2014, at 23:53, Nikita Popov nikita@gmail.com wrote: [...] As such I'm re-proposing this RFC for inclusion in PHP 7: https://wiki.php.net/rfc/engine_exceptions_for_php7 The RFC text is essentially the same as previously, with the primary difference being that parse errors are now converted to exceptions as well. This was previously not possible due to limitations in the compiler design. I very much like the idea of making fatal errors exceptions, so: thumbs up! Is there a way to introduce different exception classes for different errors. E.g. - UndefinedMethodException for stdClass::method() - NullPointerException for null::method() - UndefinedFunctionException for invalid_function() - etc. They could all extend EngineException to have a common base class but I am sure we could find good abstractions for an exception inheritance tree. What do you think? It was suggested in the previous discussion that this could be added later, but IMHO, it's a must. Part of the power of exceptions is that you can *selectively* catch them *when you know you can deal with the result*. Emitting a single EngineException will just encourage a kind of pokemon exception handling, because the only way to use it is in a generic something went wrong handler. The semantics of that handler might be a bit tidier than one for E_RECOVERABLE_ERROR, but there's not a lot of extra power available. As an example where a specific exception would be useful, but a generic one would not, consider a fluent interface which sometimes bugs out and returns NULL. If wrapped in a NullPointerException these expected error conditions could be caught at runtime, while any other errors would continue to have their normal behaviour (such as triggering a higher-scoped catch-all/default exception handler). Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
On 07.10.2014 14:15, Ferenc Kovacs wrote: yes, this was also suggested before, but that will be also a BC break for those people already using the name of the new parent class ( https://github.com/search?l=phpq=EngineExceptiontype=Codeutf8=%E2%9C%93 for example). which can be still an ok decision, I'm just stating/repeating the pro/cons as this was all discussed before. It should be considered that most of the results of this links are using namespaces, the minority doesn't. And those ask for trouble anyway, IMHO, if they don't use any kind of namespacing (be it old PEAR conventions or using real namespaces). - Markus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
On Tue, Oct 7, 2014 at 7:58 AM, Rowan Collins rowan.coll...@gmail.com wrote: Lars Strojny wrote (on 06/10/2014): Hi Nikita, On 06 Oct 2014, at 23:53, Nikita Popov nikita@gmail.com wrote: [...] As such I'm re-proposing this RFC for inclusion in PHP 7: https://wiki.php.net/rfc/engine_exceptions_for_php7 The RFC text is essentially the same as previously, with the primary difference being that parse errors are now converted to exceptions as well. This was previously not possible due to limitations in the compiler design. I very much like the idea of making fatal errors exceptions, so: thumbs up! Is there a way to introduce different exception classes for different errors. E.g. - UndefinedMethodException for stdClass::method() - NullPointerException for null::method() - UndefinedFunctionException for invalid_function() - etc. They could all extend EngineException to have a common base class but I am sure we could find good abstractions for an exception inheritance tree. What do you think? It was suggested in the previous discussion that this could be added later, but IMHO, it's a must. Part of the power of exceptions is that you can *selectively* catch them *when you know you can deal with the result*. Emitting a single EngineException will just encourage a kind of pokemon exception handling, because the only way to use it is in a generic something went wrong handler. The semantics of that handler might be a bit tidier than one for E_RECOVERABLE_ERROR, but there's not a lot of extra power available. As an example where a specific exception would be useful, but a generic one would not, consider a fluent interface which sometimes bugs out and returns NULL. If wrapped in a NullPointerException these expected error conditions could be caught at runtime, while any other errors would continue to have their normal behaviour (such as triggering a higher-scoped catch-all/default exception handler). I would contend that catching a NullPointerException is not any more recoverable than most other EngineExceptions. I would also argue that you should never, in any language, catch a NPE. The only time you should catch an NPE is if you are catching all exceptions, such as in a FastCGI daemon that will cleanly shutdown afterwards. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
Hi! yes, this was also suggested before, but that will be also a BC break for those people already using the name of the new parent class (https://github.com/search?l=phpq=EngineExceptiontype=Codeutf8=%E2%9C%93 for example). This btw looks like a bigger issue (though many of them are namespaced). Maybe we shoud do \PHP\EngineException? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
Hi! 1) I'm not sure if cacth(Exception $e) should catch engine and parser exceptions. May be it's better to introduce interface or common parent class Catchable and then make Exception, EngineException and ParseException implement it. In case user would like to catch all the error at once they will able to use catch(Catchable $e), but cacth(Exception $e) would be 100% compatible. We had some requests for 'Throwable' class/interface for some time, e.g.: https://bugs.php.net/bug.php?id=48599 Maybe we could borrow something from Java here (http://docs.oracle.com/javase/6/docs/api/java/lang/Throwable.html) - not sure if it's the best way but it's an option. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
On 7 October 2014 18:52:35 GMT+01:00, Levi Morrison le...@php.net wrote: On Tue, Oct 7, 2014 at 7:58 AM, Rowan Collins rowan.coll...@gmail.com wrote: As an example where a specific exception would be useful, but a generic one would not, consider a fluent interface which sometimes bugs out and returns NULL. If wrapped in a NullPointerException these expected error conditions could be caught at runtime, while any other errors would continue to have their normal behaviour (such as triggering a higher-scoped catch-all/default exception handler). I would contend that catching a NullPointerException is not any more recoverable than most other EngineExceptions. In the scenario I just listed, the catch is effectively emulating an isset()/is_object() check before each chained operation. Seems perfectly reasonable to me. (If I'm not much mistaken, CoffeeScript has an operator for this precise case.) I would also argue that you should never, in any language, catch a NPE. The only time you should catch an NPE is if you are catching all exceptions, such as in a FastCGI daemon that will cleanly shutdown afterwards. If you're not allowed to catch it, why make it an exception? Benefits such as unwinding finally blocks and destructors, and collecting backtraces, are secondary effects, not really fundamental to exceptions. Perhaps NullPointerException is not a good name, as it has rather different implications than in other languages. In PHP, using the - operator on a non-object isn't much different from calling a function with incorrect types. It shouldn't happen if your code is properly unit-tested, but it doesn't necessarily mean a catastrophic failure has occurred. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
I would also argue that you should never, in any language, catch a NPE. The only time you should catch an NPE is if you are catching all exceptions, such as in a FastCGI daemon that will cleanly shutdown afterwards. If you're not allowed to catch it, why make it an exception? Benefits such as unwinding finally blocks and destructors, and collecting backtraces, are secondary effects, not really fundamental to exceptions. This is not a new idea; a very quick search turned up the CERT Oracle Coding Standard for Java: Programs must not catch java.lang.NullPointerException. A NullPointerException exception thrown at runtime indicates the existence of an underlying null pointer dereference that must be fixed in the application code[...] Handling the underlying null pointer dereference by catching the NullPointerException rather than fixing the underlying problem is inappropriate for several reasons. I'll let you read the standard for the justification. The point is that a few applications (and I mean a *very* few) need to be able to handle these kinds of failures; for example a web server shouldn't crash because the application throws a NullPointerException; rather the worker dies and the client will be sent a 500 error and the web server continues to run normally. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
On 07/10/2014 21:07, Levi Morrison wrote:
I would also argue that
you should never, in any language, catch a NPE. The only time you
should catch an NPE is if you are catching all exceptions, such as in
a FastCGI daemon that will cleanly shutdown afterwards.
If you're not allowed to catch it, why make it an exception? Benefits such as
unwinding finally blocks and destructors, and collecting backtraces, are
secondary effects, not really fundamental to exceptions.
This is not a new idea; a very quick search turned up the CERT Oracle
Coding Standard for Java:
Programs must not catch java.lang.NullPointerException. A
NullPointerException exception thrown at runtime indicates the
existence of an underlying null pointer dereference that must be fixed
in the application code[...] Handling the underlying null pointer
dereference by catching the NullPointerException rather than fixing
the underlying problem is inappropriate for several reasons.
I'll let you read the standard for the justification.
Assuming you mean this (you forgot the link, so I searched the quote):
https://www.securecoding.cert.org/confluence/display/java/ERR08-J.+Do+not+catch+NullPointerException+or+any+of+its+ancestors
They give 3 reasons:
1) Performance overhead.
I have no idea whether this is true for PHP's implementation of
Exceptions, or for the scenario which I came up with earlier.
2) Inability to know which part of the try{} block initiated the error.
This is a fair point, although why it is more true of these exceptions
than any other, I'm not sure.
3) programs rarely remain in an expected and usable state after a
|NullPointerException| has been thrown
As mentioned earlier, PHP is not Java, and the closest to a Null
Pointer is actually variable which you thought was going to be an
object but turned out to be a scalar or array. The situations that lead
to the exception are vastly different, so the chances of recoverability
aren't really generalisable from one to the other.
To clarify, this is the kind of code I was thinking of:
$result = DataSource::newInstance()
-select('foo')
-from('bar')
-with('baz') // WHAT IF THIS RETURNS FALSE?
-using('id')
-where('foo_name', $name)
-and('active', true)
-fetchArray();
There are two ways I know of for dealing with an error midway through a
chain like that:
1) Return a Null Object, or an object which has been put into an error
state, so that all following calls are executed, but do nothing.
2) Throw an exception, so that the chain finishes early, and the calling
code knows an error has occurred.
If the library author has done neither of these, you will be faced with
a call to a member-function on a non-object error. Your only recourse
if you cannot / are unwilling to fix the library is to remove the
elegance of the fluent interface and check an intermediate variable with
is_object() or instanceOf on every line.
If that was an exception, then you, as the library consumer, could catch
it, just like you would catch a custom exception thrown by a more
conscientious library author.
The point is that a few applications (and I mean a*very* few) need to
be able to handle these kinds of failures; for example a web server
shouldn't crash because the application throws a NullPointerException;
rather the worker dies and the client will be sent a 500 error and the
web server continues to run normally.
Just to clarify, are you broadly in favour of Engine Exceptions, or
against the whole idea? Because this sounds like a call for something
completely separated from the userland notion of Exception, and indeed
something that would rarely even be written in PHP rather than C in an
extension.
Regards,
--
Rowan Collins
[IMSoP]
Re: [PHP-DEV] [RFC] Exceptions in the engine
Hi Nikita, On 06 Oct 2014, at 23:53, Nikita Popov nikita@gmail.com wrote: [...] As such I'm re-proposing this RFC for inclusion in PHP 7: https://wiki.php.net/rfc/engine_exceptions_for_php7 The RFC text is essentially the same as previously, with the primary difference being that parse errors are now converted to exceptions as well. This was previously not possible due to limitations in the compiler design. I very much like the idea of making fatal errors exceptions, so: thumbs up! Is there a way to introduce different exception classes for different errors. E.g. - UndefinedMethodException for stdClass::method() - NullPointerException for null::method() - UndefinedFunctionException for invalid_function() - etc. They could all extend EngineException to have a common base class but I am sure we could find good abstractions for an exception inheritance tree. What do you think? cu, Lars signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [PHP-DEV] [RFC] Exceptions in the engine
Hi! As such I'm re-proposing this RFC for inclusion in PHP 7: https://wiki.php.net/rfc/engine_exceptions_for_php7 The RFC text is essentially the same as previously, with the primary difference being that parse errors are now converted to exceptions as well. This was previously not possible due to limitations in the compiler design. I like this. Fatal errors and warnings were for a long time in different leagues, and the need to handle them better produced E_RECOVERABLE_ERROR which is a weird creature - like exception but not quite. I think PHP 7 is a good time to move to exceptions for real errors (as opposed to informational messages like E_WARNING). The only issue I think we need to discuss is catch(Exception $e). Now it would catch much more than before, if we do no changes. Should we allow it or should be have hierarchy that separates user exceptions and engine exceptions, and have catch(Exception) catch only the former. However, I see in the RFC it does not remove all the errors. I think we need to strive for having all the non-core errors except for out of memory and timeout be converted. Are there ones that are problematic to convert or it is just the question of time/effort? About the long error message - I usually wouldn't recommend that but maybe here is a good place for an ini setting, saying if we really want to display the stack trace for uncaught exceptions? In many production systems, wasting time to collect and then print the backtrace may not be needed, and one-point message is enough. Many tools already have such option (xdebug included) so maybe if we move to exceptions core may have something like that too? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
On 27/10/2013 15:51, Nikita Popov wrote: Unless we have *concrete* plans regarding PHP 6 saying this should go into (a hypothetical, non-existing) PHP 6 is roughly equivalent to just declining the feature. I agree with that, and think it is a real problem, but there are two solutions: abandon the BC rules for 5.x releases, or make some concrete plans for 6.x. Otherwise, the release process might as well not distinguish minor and major releases at all, and just define what is and isn't allowed in terms of BC for the foreseeable future of PHP. PHP 6 only makes sense to me if we're planning to actually do changes with major BC impact. Not things like this RFC, but changes of basic language semantics (like fixing the 0 == foo comparison and other foundational issues). Not every major release has to fix everything. An overhaul of error handling, in general, would seem like a good Big Feature to pin a major release on, just as Unicode strings would have been, had it gone ahead. -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
On Sun, Oct 27, 2013 at 5:11 PM, Rowan Collins rowan.coll...@gmail.com wrote: On 27/10/2013 15:51, Nikita Popov wrote: Unless we have *concrete* plans regarding PHP 6 saying this should go into (a hypothetical, non-existing) PHP 6 is roughly equivalent to just declining the feature. Not sure where Nikita posted that, so I will comment here :) No, it is about defining what is good in 5.x and what is good for a future 6.x. Also the 6.x discussion should be taken in a separate thread. But I won't suggest to do it now, let keep us focused on getting 5.6 out in time decide what goes in 5.6. I agree with that, and think it is a real problem, but there are two solutions: abandon the BC rules for 5.x releases, or make some concrete plans for 6.x. It is not the time now to make plan for 6.x. But to decide what goes in 5.6 or not. Otherwise, the release process might as well not distinguish minor and major releases at all, and just define what is and isn't allowed in terms of BC for the foreseeable future of PHP. That's what it does, both parts. And we can develop a 6.x branch in parallel to 5.x, f.e. 5.6.x and 5.7. The key here is to decide what are the key big changes we want in (tsrm drop, TLS support, general exceptions usage could be some of them). Cheers. -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
On 27/10/2013 15:51, Nikita Popov wrote: The question is always how big is the break? not is there a break?. The latter question doesn't even make sense because any change to PHP - including the most trivial bugfixes - breaks compatibility to *some* degree (well, unless the change is fix whitespace in foo.c) Obligatory XKCD: http://xkcd.com/1172/ A fair point, and trust Randall to be the one to capture its essence. I guess the question then is, if the changes are so minor, are the benefits actually any bigger than the drawbacks? As part of a move towards changing error handling in general, it's a good idea, but that implies it is the first milestone in some larger plan, which doesn't seem to be the case as yet. -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
On Fri, Oct 25, 2013 at 3:55 PM, Richard Bradley richard.brad...@softwire.com wrote: How could anything be reliant on the behaviour of a fatal error in any meaningful way ?? Cheers Joe In plenty of ways: for example currently frameworks can catch fatal errors using register_shutdown_function and display an error page to the end user (say if there is an attempt to call a method on a null object due to an unanticipated runtime error). Current frameworks might be broken if the way fatal errors work is changed. That would be a BC break. See e.g. http://stackoverflow.com/questions/16284235/zend-framework-error-page-for-php-fatal-errors/16284260#16284260 (This is not a vote for or against this proposal; I'm just answering the immediate parent here.) Wouldn't this sort of use case be covered by the fact that an uncaught exception would still result in a fatal error? The only case it'd break is if you have a try/catch around your entire application, before you had to listen to have a shutdown handler but now your catch would catch the fatal exceptions before they bring everything down. I'd imagine that this RFC would not affect most sane cases of shutdown handlers and related show a nice error page to users when all hell breaks loose tricks. Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
On 24/10/2013 18:41, Nikita Popov wrote: Hi internals! I'd like to propose an RFC, which allows the use of exceptions within the engine and also allows changing existing fatal errors to exceptions: https://wiki.php.net/rfc/engine_exceptions This topic has been cropping up in the discussions for several of the recent RFCs and I think the time has come to consider moving away from fatal errors. Thoughts? Thanks, Nikita I love this proposal! Errors are a very dated way of handling errors, and there are a lot of fatal errors which are unnecessarily fatal. This would mean many could stop being fatal and start being exceptions, which is great news. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
On Thu, 2013-10-24 at 19:41 +0200, Nikita Popov wrote: Hi internals! I'd like to propose an RFC, which allows the use of exceptions within the engine and also allows changing existing fatal errors to exceptions: If there is a way to recover from a fatal error it shouldn't be E_ERROR but E_RECOVERABLE. Catching E_RECOVERABLE is a pita. this should be replaced by exceptions imo. E_FATAL should stay for things where it is too much trouble to recover as the engine is in undefined state. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
Hi! Looking at the patch, it converts zend_error_noreturn into ZEND_IMPOSSIBLE, which is nothing in non-debug mode. This means code that expected that execution ceases it this point (and jumps to a safe bail-out point) now just continues in non-debug mode (probably causing crash or memory corruption) or exits the process on failed assert in debug mode. I'm not sure it is a good idea to do this. A lot of code assumes execution does not proceed past E_ERROR, but exceptions do not work that way. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
