Hi Nikita
-Ursprüngliche Nachricht-
Von: Nikita Popov [mailto:nikita@gmail.com]
Gesendet: Montag, 6. Oktober 2014 23:54
An: PHP internals
Betreff: [PHP-DEV] [RFC] Exceptions in the engine
Hi internals!
During the PHP 5.6 development cycle I have proposed an RFC [1
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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,
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
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
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
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.
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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,
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
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
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
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:
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
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
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
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
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
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
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
56 matches
Mail list logo
