Hi internals!
Voting on the engine exceptions RFC, which proposes to convert existing
fatal and recoverable fatal errors into exceptions, has opened:
https://wiki.php.net/rfc/engine_exceptions_for_php7#vote
The primary vote requires a 2/3 majority, as this is a language change.
A second vote will decide whether to use a BaseException based inheritance
hierarchy. This vote uses a simple majority.
Voting is open until 2015-03-08.
Nikita
Hi Nikita,
Voting on the engine exceptions RFC, which proposes to convert existing
fatal and recoverable fatal errors into exceptions, has opened:https://wiki.php.net/rfc/engine_exceptions_for_php7#voteThe primary vote requires a 2/3 majority, as this is a language change.
A second vote will decide whether to use a BaseException based inheritance
hierarchy. This vote uses a simple majority.
Although, AbstractException sounds better to me. I voted "yes" for it now.
We probably need more specific coding standard for class/interface names
for internal
classes/interfaces.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Nikita,
Voting on the engine exceptions RFC, which proposes to convert existing
fatal and recoverable fatal errors into exceptions, has opened:https://wiki.php.net/rfc/engine_exceptions_for_php7#voteThe primary vote requires a 2/3 majority, as this is a language change.
A second vote will decide whether to use a BaseException based inheritance
hierarchy. This vote uses a simple majority.Although, AbstractException sounds better to me. I voted "yes" for it now.
We probably need more specific coding standard for class/interface names
for internal
classes/interfaces.Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hello,
I personally find both BaseException and AbstractException ugly. The
"Throwable" is IMHO much better.
Regards
Pavel Kouril
Hi all,
I personally find both BaseException and AbstractException ugly. The
"Throwable" is IMHO much better.
We definitely need coding(naming) standard :)
We may have coding standard before PHP7 release and cleanup all.
For people dislike BaseException, please do not vote "no" only for this.
It may be changed later.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi,
Am 23.02.2015 um 19:15 schrieb Nikita Popov:
A second vote will decide whether to use a BaseException based inheritance
hierarchy. This vote uses a simple majority.
I like this RFC and hope it passes. I am a little concerned about
littering the global namespace. It would be preferable to have a single
namespace that is reserved for all build in classes (like \PHP) that
contains all classes like exceptions. The name BaseException seems to be
a very common one:
https://github.com/search?l=php&q=baseexception&type=Code finds about
14k matches, so this may be a huge BC break if the actual class name is
not changed.
Thanks
Dennis
Hi all,
On Tue, Feb 24, 2015 at 8:04 PM, Dennis Birkholz dennis@birkholz.biz
wrote:
Am 23.02.2015 um 19:15 schrieb Nikita Popov:
A second vote will decide whether to use a BaseException based
inheritance
hierarchy. This vote uses a simple majority.I like this RFC and hope it passes. I am a little concerned about
littering the global namespace. It would be preferable to have a single
namespace that is reserved for all build in classes (like \PHP) that
contains all classes like exceptions. The name BaseException seems to be
a very common one:
https://github.com/search?l=php&q=baseexception&type=Code finds about
14k matches, so this may be a huge BC break if the actual class name is
not changed.
It seems AbstractException is better choice for BC.
https://github.com/search?l=php&q=abstractexception&ref=searchresults&type=Code
There are 661 matches, but most of them are using namespace unlike
BaseException.
Someone proposed to use namespace for all PHP functions/classes and
clean global namespace up. This gives us flexibility also. e.g Providing
compatibility to older functions/classes to mitigate BC impact.
Use of namespace is BC by itself, but it may be better to consider namespace
use for internal features. We don't have much time, so it may be for PHP8...
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
2015-02-24 13:29 GMT+01:00 Yasuo Ohgaki yohgaki@ohgaki.net:
Hi all,
On Tue, Feb 24, 2015 at 8:04 PM, Dennis Birkholz dennis@birkholz.biz
wrote:Am 23.02.2015 um 19:15 schrieb Nikita Popov:
A second vote will decide whether to use a BaseException based
inheritance
hierarchy. This vote uses a simple majority.I like this RFC and hope it passes. I am a little concerned about
littering the global namespace. It would be preferable to have a single
namespace that is reserved for all build in classes (like \PHP) that
contains all classes like exceptions. The name BaseException seems to be
a very common one:
https://github.com/search?l=php&q=baseexception&type=Code finds about
14k matches, so this may be a huge BC break if the actual class name is
not changed.It seems AbstractException is better choice for BC.
https://github.com/search?l=php&q=abstractexception&ref=searchresults&type=Code
There are 661 matches, but most of them are using namespace unlike
BaseException.Someone proposed to use namespace for all PHP functions/classes and
clean global namespace up. This gives us flexibility also. e.g Providing
compatibility to older functions/classes to mitigate BC impact.Use of namespace is BC by itself, but it may be better to consider
namespace
use for internal features. We don't have much time, so it may be for
PHP8...
All "none" namespaced classnames are IMO reserved for PHP....
So if you develop an application/classes you (should) always prefix a
vendor/project namesapce.
But +1 for PHP8+ for a PHP namespace. For PHP7 please do not do too much at
once.
Am 23.02.2015 um 19:15 schrieb Nikita Popov:
Voting on the engine exceptions RFC, which proposes to convert existing
fatal and recoverable fatal errors into exceptions, has opened:https://wiki.php.net/rfc/engine_exceptions_for_php7#voteThe primary vote requires a 2/3 majority, as this is a language change.
A second vote will decide whether to use a BaseException based inheritance
hierarchy. This vote uses a simple majority.
I have voted yes on "Allow exceptions in the engine and conversion of
existing fatals?" and no on "Introduce and use BaseException?" and
would like to elaborate on the latter.
I am sorry that I was unable to raise this concern earlier (did not
really become aware of the RFC before it was put to the vote), but I
would prefer the following:
- Introduce a Throwable interface
- Let Exception implement the Throwable interface
- Introduce an Error class that implements the Throwable interface
- Use Error class as base class for exceptions raised by the engine
This would be along the lines of what Java does.
Am 23.02.2015 um 19:15 schrieb Nikita Popov:
Voting on the engine exceptions RFC, which proposes to convert existing
fatal and recoverable fatal errors into exceptions, has opened:https://wiki.php.net/rfc/engine_exceptions_for_php7#voteThe primary vote requires a 2/3 majority, as this is a language change.
A second vote will decide whether to use a BaseException based inheritance
hierarchy. This vote uses a simple majority.I have voted yes on "Allow exceptions in the engine and conversion of
existing fatals?" and no on "Introduce and use BaseException?" and
would like to elaborate on the latter.I am sorry that I was unable to raise this concern earlier (did not
really become aware of the RFC before it was put to the vote), but I
would prefer the following:* Introduce a Throwable interface * Let Exception implement the Throwable interface * Introduce an Error class that implements the Throwable interface * Use Error class as base class for exceptions raised by the engineThis would be along the lines of what Java does.
+1 on that, and as it seems the BaseException is going to pass, it might
be good to quickly draft another RFC to amend that part.
It seems people in general favor the fact that catch(Exception $e) does
not catch those new engine exceptions, but there hopefully would not be
much resistance against a cleaner scheme than a BaseException class.
Also the Error (and possibly Throwable) class/interface might be put in
a PHP namespace and then we avoid any potential BC issues, but that's
perhaps another voting point :)
Cheers
+1 on Sebastian's suggestion. =)
I volunteer to either update the RFC or create a new one to resolve this
once "Exceptions in the engine" passes (which looks like a reality already
to me).
Just tell me which approach I should take and I'll happily write the RFC.
[]s,
Am 23.02.2015 um 19:15 schrieb Nikita Popov:
Voting on the engine exceptions RFC, which proposes to convert existing
fatal and recoverable fatal errors into exceptions, has opened:https://wiki.php.net/rfc/engine_exceptions_for_php7#voteThe primary vote requires a 2/3 majority, as this is a language change.
A second vote will decide whether to use a BaseException based
inheritance
hierarchy. This vote uses a simple majority.I have voted yes on "Allow exceptions in the engine and conversion of
existing fatals?" and no on "Introduce and use BaseException?" and
would like to elaborate on the latter.I am sorry that I was unable to raise this concern earlier (did not
really become aware of the RFC before it was put to the vote), but I
would prefer the following:* Introduce a Throwable interface * Let Exception implement the Throwable interface * Introduce an Error class that implements the Throwable interface * Use Error class as base class for exceptions raised by the engineThis would be along the lines of what Java does.
+1 on that, and as it seems the BaseException is going to pass, it might
be good to quickly draft another RFC to amend that part.It seems people in general favor the fact that catch(Exception $e) does
not catch those new engine exceptions, but there hopefully would not be
much resistance against a cleaner scheme than a BaseException class.Also the Error (and possibly Throwable) class/interface might be put in a
PHP namespace and then we avoid any potential BC issues, but that's perhaps
another voting point :)Cheers
--
--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
+1 on Sebastian's suggestion. =)
I volunteer to either update the RFC or create a new one to resolve this
once "Exceptions in the engine" passes (which looks like a reality already
to me).Just tell me which approach I should take and I'll happily write the RFC.
[]s,
The RFC is currently in voting, so editing it directly is a no-no. A
new, short RFC, please. (Exception implements Throwable, Error
implements Throwable sounds good to me. Should we ask about
SomeUserspaceClass implements Throwable, or will someone hit me for that?)
--Larry Garfield
Am 28.02.2015 um 01:57 schrieb Larry Garfield:
The RFC is currently in voting, so editing it directly is a no-no. A new,
short RFC, please. (Exception implements Throwable, Error implements
Throwable sounds good to me. Should we ask about SomeUserspaceClass
implements Throwable, or will someone hit me for that?)
I don't think Throwable should be implementable by userland classes.
Please, write additional RFC if you are ready to work on it and provide
implementation.
The class hierarchy is definitely not the main part of this one.
The idea was just to make difference between Exception, EngineException and
ParseException.
Thanks. Dmirty.
Am 23.02.2015 um 19:15 schrieb Nikita Popov:
Voting on the engine exceptions RFC, which proposes to convert existing
fatal and recoverable fatal errors into exceptions, has opened:https://wiki.php.net/rfc/engine_exceptions_for_php7#voteThe primary vote requires a 2/3 majority, as this is a language change.
A second vote will decide whether to use a BaseException based
inheritance
hierarchy. This vote uses a simple majority.I have voted yes on "Allow exceptions in the engine and conversion of
existing fatals?" and no on "Introduce and use BaseException?" and
would like to elaborate on the latter.I am sorry that I was unable to raise this concern earlier (did not
really become aware of the RFC before it was put to the vote), but I
would prefer the following:* Introduce a Throwable interface * Let Exception implement the Throwable interface * Introduce an Error class that implements the Throwable interface * Use Error class as base class for exceptions raised by the engineThis would be along the lines of what Java does.
+1 on that, and as it seems the BaseException is going to pass, it might
be good to quickly draft another RFC to amend that part.It seems people in general favor the fact that catch(Exception $e) does
not catch those new engine exceptions, but there hopefully would not be
much resistance against a cleaner scheme than a BaseException class.Also the Error (and possibly Throwable) class/interface might be put in a
PHP namespace and then we avoid any potential BC issues, but that's perhaps
another voting point :)Cheers
Am 27.02.2015 um 15:47 schrieb Jordi Boggiano:
quickly draft another RFC to amend that part
So who will draft the RFC for
- Introduce a Throwable interface
- Let Exception implement the Throwable interface
- Introduce an Error class that implements the Throwable interface
- Use Error class as base class for exceptions raised by the engine
?
Am 15.03.2015 um 08:07 schrieb Sebastian Bergmann:
So who will draft the RFC for
- Introduce a Throwable interface
- Let Exception implement the Throwable interface
- Introduce an Error class that implements the Throwable interface
- Use Error class as base class for exceptions raised by the engine
?
It was my idea, after all, only fair that I invest the time to make
it into an RFC: https://wiki.php.net/rfc/throwable
Please let me know if there is anything missing.
Am 15.03.2015 um 08:07 schrieb Sebastian Bergmann:
So who will draft the RFC for
- Introduce a Throwable interface
- Let Exception implement the Throwable interface
- Introduce an Error class that implements the Throwable interface
- Use Error class as base class for exceptions raised by the engine
?
It was my idea, after all, only fair that I invest the time to make
it into an RFC: https://wiki.php.net/rfc/throwablePlease let me know if there is anything missing.
--
Hello,
why global namespace? Why not just starting using namespaces for PHP
stuff? The global namespace gets more and more polluted by this IMHO.
Regards
Pavel Kouril
Am 15.03.2015 um 09:24 schrieb Pavel Kouřil:
why global namespace?
Because that is where, as of today, built-in classes, interfaces,
functions, etc. go.
The introduction of a PHP namespace, for instance, would be the topic
of a separate RFC.
Am 15.03.2015 um 08:27 schrieb Sebastian Bergmann:
It was my idea, after all, only fair that I invest the time to make
it into an RFC: https://wiki.php.net/rfc/throwable
The vote for this missed the boat for the PHP 7 deadline. However, if
we really want to do this we should do it in PHP 7 or not at all (at
least not for a long time) due to BC breaks.
Thoughts?
Hi Sebastian,
On Sun, Mar 22, 2015 at 2:05 AM, Sebastian Bergmann sebastian@php.net
wrote:
Am 15.03.2015 um 08:27 schrieb Sebastian Bergmann:
It was my idea, after all, only fair that I invest the time to make
it into an RFC: https://wiki.php.net/rfc/throwableThe vote for this missed the boat for the PHP 7 deadline. However, if
we really want to do this we should do it in PHP 7 or not at all (at
least not for a long time) due to BC breaks.Thoughts?
It seems "BaseException" breaks many apps compare to proposed classes.
We need to adjust how/which exception is raised.
I'm +1 for this change.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Am 21.03.2015 um 18:05 schrieb Sebastian Bergmann:
The vote for this missed the boat for the PHP 7 deadline. However, if
we really want to do this we should do it in PHP 7 or not at all (at
least not for a long time) due to BC breaks.Thoughts?
ping
Hi!
The vote for this missed the boat for the PHP 7 deadline. However, if
we really want to do this we should do it in PHP 7 or not at all (at
least not for a long time) due to BC breaks.Thoughts?
It's kind of hard to recover the context here, but I assume it's
https://wiki.php.net/rfc/throwable and replacing BaseException with
Throwable. I like the idea, however we do have the deadline and the
deadline has been passed. So I wonder if we can't keep it for 7.1 with
the following modification (assuming the RFC passes):
- BaseException implements Throwable
- BaseException is deprecated in 7.1
- BaseException is removed in 7.2 or 8.0
Also I don't see Error class though it was mentioned in the previous
discussion. Was it dropped for a reason?
Stas Malyshev
smalyshev@gmail.com
Am 30.04.2015 um 02:50 schrieb Stanislav Malyshev:
I like the idea, however we do have the deadline and the
deadline has been passed. So I wonder if we can't keep it for 7.1
That means introducing a change in 7.0, changing it and deprecating
part of it in 7.1, and removing said part in 7.2/8.0. Makes no sense
to me. Either do it now for 7.0 or don't do it.
On Thu, Apr 30, 2015 at 6:51 AM, Sebastian Bergmann sebastian@php.net
wrote:
Am 30.04.2015 um 02:50 schrieb Stanislav Malyshev:
I like the idea, however we do have the deadline and the
deadline has been passed. So I wonder if we can't keep it for 7.1That means introducing a change in 7.0, changing it and deprecating
part of it in 7.1, and removing said part in 7.2/8.0. Makes no sense
to me. Either do it now for 7.0 or don't do it.
I tend to agree here.
If we introduce BaseException, deprecating it one year later (probably) is
a bad idea IMO.
We could make an exception (sic !) and add the Throwable interface to PHP7,
even after feature freeze, because it is an easy pick and having a clear
Exception model for 7.0 is to my opinion very important.
Julien.Pauli
Am 30.04.2015 um 14:30 schrieb Julien Pauli:
We could make an exception (sic !) and add the Throwable interface to PHP7,
even after feature freeze, because it is an easy pick and having a clear
Exception model for 7.0 is to my opinion very important.
+1, couldn't agree more.
Am 30.04.2015 um 14:30 schrieb Julien Pauli:
On Thu, Apr 30, 2015 at 6:51 AM, Sebastian Bergmann sebastian@php.net
wrote:Am 30.04.2015 um 02:50 schrieb Stanislav Malyshev:
I like the idea, however we do have the deadline and the
deadline has been passed. So I wonder if we can't keep it for 7.1
That means introducing a change in 7.0, changing it and deprecating
part of it in 7.1, and removing said part in 7.2/8.0. Makes no sense
to me. Either do it now for 7.0 or don't do it.I tend to agree here.
If we introduce BaseException, deprecating it one year later (probably) is
a bad idea IMO.We could make an exception (sic !) and add the Throwable interface to PHP7,
even after feature freeze, because it is an easy pick and having a clear
Exception model for 7.0 is to my opinion very important.
This would be very great!
If I remember right, on base discussion the BaseException vs. Throwable
interface was called an implementation detail that can be changed later
on. And on vote it was only some weeks before feature freeze so it would
be impossible for the Throwable interface to pass before freeze.
Julien.Pauli
Marc
Hi!
We could make an exception (sic !) and add the Throwable interface to PHP7,
even after feature freeze, because it is an easy pick and having a clear
Exception model for 7.0 is to my opinion very important.
I'm OK with it but I fear this is opening a can of worms, since people
will start arguing "well, we've added Throwable so let's also add this
other thing which is absolutely 100% necessary" and here goes our
feature freeze. Maybe I'm just too cynical :) Anyway, I don't have any
objection on substance to it. So if everybody is ok with it, I'm fine
with it too.
Stas Malyshev
smalyshev@gmail.com
Hi Stas,
2015-04-30 13:51 GMT-03:00 Stanislav Malyshev smalyshev@gmail.com:
Hi!
We could make an exception (sic !) and add the Throwable interface to
PHP7,
even after feature freeze, because it is an easy pick and having a clear
Exception model for 7.0 is to my opinion very important.I'm OK with it but I fear this is opening a can of worms, since people
will start arguing "well, we've added Throwable so let's also add this
other thing which is absolutely 100% necessary" and here goes our
feature freeze. Maybe I'm just too cynical :) Anyway, I don't have any
objection on substance to it. So if everybody is ok with it, I'm fine
with it too.Stas Malyshev
smalyshev@gmail.com--
I agree with you, but the process isn't perfect - and will never be. Taking
RFC guidelines without exceptions is damaging to quality in this case. If
someone else decide to open a new RFC after the deadline without the same
level of consensus we have here, the RFC will be put down, hopefully.
Thanks.
Hi Stas,
2015-04-30 13:51 GMT-03:00 Stanislav Malyshev smalyshev@gmail.com:
Hi!
We could make an exception (sic !) and add the Throwable interface to
PHP7,
even after feature freeze, because it is an easy pick and having a
clear
Exception model for 7.0 is to my opinion very important.I'm OK with it but I fear this is opening a can of worms, since people
will start arguing "well, we've added Throwable so let's also add this
other thing which is absolutely 100% necessary" and here goes our
feature freeze. Maybe I'm just too cynical :) Anyway, I don't have any
objection on substance to it. So if everybody is ok with it, I'm fine
with it too.Stas Malyshev
smalyshev@gmail.com--
I agree with you, but the process isn't perfect - and will never be.
Taking
RFC guidelines without exceptions is damaging to quality in this case. If
someone else decide to open a new RFC after the deadline without the same
level of consensus we have here, the RFC will be put down, hopefully.
Let do a rfc to accept to post pone features freeze with a list or a single
RFC. I totally agree that this exact problem has to be fixed for 7.0, same
for error cb. I don't see anything else being so critical that it has to be
in 7.0.
My point for error cb is that it requires quite some changes in extensions
and if we like to avoid a 7.0 to 7.1 migration pain, it has to be in 7.0.
Thanks.
Am 01.05.2015 um 07:08 schrieb Pierre Joye:
Let do a rfc to accept to post pone features freeze with a list or a single
RFC.
Do you volunteer to draft that RFC?
Am 01.05.2015 um 07:08 schrieb Pierre Joye:
Let do a rfc to accept to post pone features freeze with a list or a single
RFC.Do you volunteer to draft that RFC?
I could but no, I am not volunteering. For many reasons but the main
one is time.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
I feel like this one is different though, because there already was consensus that the current naming isn't the best, and there was support for Throwable, while voting on the "original" RFC was still open.
To adhere to the RFC process, the open RFC wasn't changed accordingly, because voting was already underway.
And then we collectively dropped the ball when it came to remembering to do this little Throwable proposal and change.
Think of it more as just a few renames to fix engine exceptions before they go out.
David
P.S. bump by the way ;)
Hi!
We could make an exception (sic !) and add the Throwable interface to PHP7,
even after feature freeze, because it is an easy pick and having a clear
Exception model for 7.0 is to my opinion very important.I'm OK with it but I fear this is opening a can of worms, since people
will start arguing "well, we've added Throwable so let's also add this
other thing which is absolutely 100% necessary" and here goes our
feature freeze. Maybe I'm just too cynical :) Anyway, I don't have any
objection on substance to it. So if everybody is ok with it, I'm fine
with it too.Stas Malyshev
smalyshev@gmail.com
Hi!
I feel like this one is different though, because there already was
consensus that the current naming isn't the best, and there was
support for Throwable, while voting on the "original" RFC was still
open.
OK, if there's consensus we can go forward with this, then let's just do
that ASAP.
--
Stas Malyshev
smalyshev@gmail.com
Am 09.05.2015 um 06:38 schrieb Stanislav Malyshev:
OK, if there's consensus we can go forward with this, then let's just do
that ASAP.
Can you implement this? Thanks!
Hi!
OK, if there's consensus we can go forward with this, then let's just do
that ASAP.Can you implement this? Thanks!
I can, except that I'm pretty busy right now. But probably will have
some time on the weekend, so I've put it on my todo list.
--
Stas Malyshev
smalyshev@gmail.com
Am 13.05.2015 um 07:40 schrieb Stanislav Malyshev:
I can, except that I'm pretty busy right now. But probably will have
some time on the weekend, so I've put it on my todo list.
Thanks!
Am 13.05.2015 um 07:40 schrieb Stanislav Malyshev:
I can, except that I'm pretty busy right now. But probably will have
some time on the weekend, so I've put it on my todo list.Thanks!
Why don't you do it? You have access and you are a very good writer. No big
C knowledge required either in this case :)
Am 13.05.2015 um 08:30 schrieb Pierre Joye:
Why don't you do it? You have access and you are a very good writer.
No big C knowledge required either in this case :)
TBH, until know I did not think I would be capable of doing it
myself. I'll look into it now.
Am 13.05.2015 um 08:30 schrieb Pierre Joye:
Why don't you do it? You have access and you are a very good writer.
No big C knowledge required either in this case :)
There was/is consensus on what I proposed back in February:
- Introduce a Throwable interface
- Let Exception implement the Throwable interface
- Introduce an Error class that implements the Throwable interface
- Use Error class as base class for exceptions raised by the engine
But as simple as the above sounds it is complicated (at least for
me) to implement (properly). Here's what I was able to come up with:
https://github.com/php/php-src/pull/1274
This should give us the following:
interface Throwable {}
abstract class BaseException implements Throwable {}
class Exception extends BaseException {}
class Error extends BaseException {}
class EngineError extends Error {}
class ParseError extends Error {}
class TypeError extends Error {}
I am not sure whether we still want the abstract BaseException
class. I left it in because I couldn't figure out how to remove
it without breaking Exception and Error.
On Wed, May 13, 2015 at 9:38 AM, Sebastian Bergmann sebastian@php.net
wrote:
Am 13.05.2015 um 08:30 schrieb Pierre Joye:
Why don't you do it? You have access and you are a very good writer.
No big C knowledge required either in this case :)There was/is consensus on what I proposed back in February:
- Introduce a Throwable interface
- Let Exception implement the Throwable interface
- Introduce an Error class that implements the Throwable interface
- Use Error class as base class for exceptions raised by the engine
But as simple as the above sounds it is complicated (at least for
me) to implement (properly). Here's what I was able to come up with:https://github.com/php/php-src/pull/1274
This should give us the following:
interface Throwable {}
abstract class BaseException implements Throwable {}
class Exception extends BaseException {}
class Error extends BaseException {}
class EngineError extends Error {}
class ParseError extends Error {}
class TypeError extends Error {}I am not sure whether we still want the abstract BaseException
class. I left it in because I couldn't figure out how to remove
it without breaking Exception and Error.Added my comments inline on the PR :-)
Julien
Am 13.05.2015 um 08:30 schrieb Pierre Joye:
Why don't you do it? You have access and you are a very good writer.
No big C knowledge required either in this case :)There was/is consensus on what I proposed back in February:
- Introduce a Throwable interface
- Let Exception implement the Throwable interface
- Introduce an Error class that implements the Throwable interface
- Use Error class as base class for exceptions raised by the engine
But as simple as the above sounds it is complicated (at least for
me) to implement (properly). Here's what I was able to come up with:https://github.com/php/php-src/pull/1274
This should give us the following:
interface Throwable {}
abstract class BaseException implements Throwable {}
class Exception extends BaseException {}
class Error extends BaseException {}
class EngineError extends Error {}
class ParseError extends Error {}
class TypeError extends Error {}I am not sure whether we still want the abstract BaseException
class. I left it in because I couldn't figure out how to remove
it without breaking Exception and Error.--
Hello,
I personally dislike the BaseException. Does it have to be there?
If it's just for sharing some behavior between Exception and Error,
wouldn't trait be an acceptable (but definitely not perfect) solution?
Regards
Pavel Kouril
I want to talk about the BC impact of what has been discussed.
Currently the meaning of this code is to catch all possible
exceptions, because all exceptions must extend \Exception:
} catch (Exception $e) {
By making some other root exception you just broke all the code that
is appropriately using the catch-all variant.
So either way it is a BC break. So let's consider other impact to help decide:
If we introduce a new root exception then the people "punished" are
the ones currently using Exception correctly. Whereas if engine
exceptions just extend Exception then the people "punished" are the
ones using it inappropriately.
Please, revert all of these changes with Error and some new root
exception and do the right thing based on logical arguments. It
makes no sense to punish the people using code correctly to avoid
punishing people misusing a feature, especially when it is a BC break
either way.
I want to talk about the BC impact of what has been discussed.
Currently the meaning of this code is to catch all possible
exceptions, because all exceptions must extend\Exception:} catch (Exception $e) {By making some other root exception you just broke all the code that
is appropriately using the catch-all variant.
That's not quite true. Currently, any code that catches all exceptions
will still issue fatal errors for, for instance, an undeclared class.
With a BaseException/Throwable, this behaviour will remain unchanged -
the error messages reported will be slightly different, but they will
still propogate to fatal errors, because the exception will be uncaught.
Now, whether catching the extra exceptions would make the code better or
worse depends entirely on the nature of the code, but it's hard to see
how code whose behaviour is completely unchanged can be considered
"broken" by the proposed hierarchy.
Please, revert all of these changes with Error and some new root
exception anddo the right thing based on logical arguments.
This was the subject of a separate vote in the RFC, which passed by 39
votes to 19. https://wiki.php.net/rfc/engine_exceptions_for_php7 The
subject of discussion at present is the exact naming of the various
classes/interfaces, not the general nature of the hierarchy.
Regards,
--
Rowan Collins
[IMSoP]
This was the subject of a separate vote in the RFC, which passed by 39 votes
to 19. https://wiki.php.net/rfc/engine_exceptions_for_php7 The subject of
discussion at present is the exact naming of the various classes/interfaces,
not the general nature of the hierarchy.
There's nothing that prevents us from reneging on that by another
vote. If it's a bad decision backed by logical arguments then we can
overturn it. Also note that barely passes at 67%. That is hardly a
landslide conclusion.
This was the subject of a separate vote in the RFC, which passed by 39 votes
to 19. https://wiki.php.net/rfc/engine_exceptions_for_php7 The subject of
discussion at present is the exact naming of the various classes/interfaces,
not the general nature of the hierarchy.There's nothing that prevents us from reneging on that by another
vote. If it's a bad decision backed by logical arguments then we can
overturn it. Also note that barely passes at 67%. That is hardly a
landslide conclusion.
I also want to draw attention to some of the people who voted against
a base exception:
- rasmus
- nikic
- sebastian
These three represent fairly different realms of focus: Rasmus has a
longer-term view, Nikita is a much more recent pickup but has brought
us some of our most excellent RFCs, and Sebastian works (almost?)
exclusively in user-land only and is the author of PHPUnit, a library
that will probably be affected by this change.
I feel like there were that many "yes" votes to a base exception
because they fully didn't understand the issues at play.
Hi!
There's nothing that prevents us from reneging on that by another
vote. If it's a bad decision backed by logical arguments then we can
That's a pretty big if, given that your only argument - that it is a BC
break - is incorrect, as in fact the set of exceptions caught before and
after change is exactly the same, and the only difference is that in the
new code, you can also catch errors, the option that you didn't have
before. Absent that argument, there's no reason to renege.
overturn it. Also note that barely passes at 67%. That is hardly a
landslide conclusion.
We're going the dangerous road here. I agree that decision taken can be
overridden if we find out it was bad decision, and that can - and
eventually will - happen. However, re-opening decision immediately after
it was agreed, without any new facts or anything changes, leads to much
worse outcomes, as with this pattern we will never be able to decide
anything as long as there is at least some small set of people that
disagree. Voting is a means of establishing common goals while having
disagreements, and a means of moving the project forward without being
blocked by each disagreement. I say this as somebody who lost my share
of votes and still disagreeing with some decisions taken, but re-opening
them immediately after taking them is worse.
--
Stas Malyshev
smalyshev@gmail.com
On Sat, May 16, 2015 at 12:28 PM, Stanislav Malyshev
smalyshev@gmail.com wrote:
Hi!
There's nothing that prevents us from reneging on that by another
vote. If it's a bad decision backed by logical arguments then we canThat's a pretty big if, given that your only argument - that it is a BC
break - is incorrect, as in fact the set of exceptions caught before and
after change is exactly the same, and the only difference is that in the
new code, you can also catch errors, the option that you didn't have
before. Absent that argument, there's no reason to renege.overturn it. Also note that barely passes at 67%. That is hardly a
landslide conclusion.We're going the dangerous road here. I agree that decision taken can be
overridden if we find out it was bad decision, and that can - and
eventually will - happen. However, re-opening decision immediately after
it was agreed, without any new facts or anything changes, leads to much
worse outcomes, as with this pattern we will never be able to decide
anything as long as there is at least some small set of people that
disagree. Voting is a means of establishing common goals while having
disagreements, and a means of moving the project forward without being
blocked by each disagreement. I say this as somebody who lost my share
of votes and still disagreeing with some decisions taken, but re-opening
them immediately after taking them is worse.
The key is that I feel like the voting body wasn't well informed. It's
not because I lost; rather it's because I feel like the people voting
yes didn't actually understand the issues at play. There is a big
difference between that and revoting after a vote didn't go my way as
an effort to try again.
Hi!
The key is that I feel like the voting body wasn't well informed. It's
not because I lost; rather it's because I feel like the people voting
yes didn't actually understand the issues at play. There is a big
difference between that and revoting after a vote didn't go my way as
an effort to try again.
If you have a specific proposal how to make the votes more informed, you
are most welcome. Protesting the result of a specific vote, post-vote,
on the grounds that "these guys don't know what they're talking about" -
does not seem very useful to me. Primarily because this argument can be
applied to virtually any vote and there's no way to arrive at a
practical conclusion distinguishing valid vote from invalid based on it
- anybody can claim that if his side lost then the other side didn't
know what they're talking about. If is a possibility that this may
indeed happen - our current voting system has very few safeguards
against uninformed voting and all you need to vote is a committer
access, which doesn't make one an expert in everything. But protesting
result of a particular vote is not the way to fix the problem, if it exists.
--
Stas Malyshev
smalyshev@gmail.com
Hi!
The key is that I feel like the voting body wasn't well informed. It's
not because I lost; rather it's because I feel like the people voting
yes didn't actually understand the issues at play. There is a big
difference between that and revoting after a vote didn't go my way as
an effort to try again.If you have a specific proposal how to make the votes more informed, you
are most welcome. Protesting the result of a specific vote, post-vote,
on the grounds that "these guys don't know what they're talking about" -
does not seem very useful to me. Primarily because this argument can be
applied to virtually any vote and there's no way to arrive at a
practical conclusion distinguishing valid vote from invalid based on it
- anybody can claim that if his side lost then the other side didn't
know what they're talking about. If is a possibility that this may
indeed happen - our current voting system has very few safeguards
against uninformed voting and all you need to vote is a committer
access, which doesn't make one an expert in everything. But protesting
result of a particular vote is not the way to fix the problem, if it exists.
The difference is that as time goes on and I've written code for PHP 7
I was hit by this issue. It's an even bigger issue than even I
realized during voting. How many people who voted on that issue have
played with the code from both scenarios? Few, I can't guarantee it
but given the historical precedent it's almost certainly true.
The difference is that as time goes on and I've written code for PHP 7
I was hit by this issue. It's an even bigger issue than even I
realized during voting. How many people who voted on that issue have
played with the code from both scenarios? Few, I can't guarantee it
but given the historical precedent it's almost certainly true.
Can you give an example of the issue you were hit with? A sample program
/ scenario, where failure to catch an EngineException caused behaviour
that was in some way worse than that under PHP 5?
Regards,
--
Rowan Collins
[IMSoP]
The difference is that as time goes on and I've written code for PHP 7
I was hit by this issue. It's an even bigger issue than even I
realized during voting. How many people who voted on that issue have
played with the code from both scenarios? Few, I can't guarantee it
but given the historical precedent it's almost certainly true.Can you give an example of the issue you were hit with? A sample program /
scenario, where failure to catch an EngineException caused behaviour that
was in some way worse than that under PHP 5?
Here's a simplified example that illustrates one issue:
<?php
set_error_handler(function(){
echo "Handled.";
});
function foo(callable $f) {}
try {
foo("bar is not callable");
} catch (Exception $e) {
echo "Caught.";
}
echo "Done.", PHP_EOL;
?>
In PHP 5 this prints "Handled.Done". Under PHP 7 this fails with:
Fatal error: Argument 1 passed to foo() must be callable, string given
Note that if the TypeException had been caught by catch (Exception $e)
the program would have still been correct. This kind of setup exists
in PHPUnit for example; even if the test has some bad syntax or
failure the testing harness needs to continue. There are other valid
uses as well.
The only way to make this work in both PHP 5 and 7 is to modify the
code, despite the program being 100% correct under PHP 5 and the
documented semantics.
The difference is that as time goes on and I've written code for PHP 7
I was hit by this issue. It's an even bigger issue than even I
realized during voting. How many people who voted on that issue have
played with the code from both scenarios? Few, I can't guarantee it
but given the historical precedent it's almost certainly true.Can you give an example of the issue you were hit with? A sample program /
scenario, where failure to catch an EngineException caused behaviour that
was in some way worse than that under PHP 5?Here's a simplified example that illustrates one issue:
<?php
set_error_handler(function(){
echo "Handled.";
});function foo(callable $f) {}
try {
foo("bar is not callable");
} catch (Exception $e) {
echo "Caught.";
}echo "Done.", PHP_EOL;
?>
In PHP 5 this prints "Handled.Done". Under PHP 7 this fails with:
Fatal error: Argument 1 passed to foo() must be callable, string given
Note that if the TypeException had been caught by catch (Exception $e)
the program would have still been correct. This kind of setup exists
in PHPUnit for example; even if the test has some bad syntax or
failure the testing harness needs to continue. There are other valid
uses as well.The only way to make this work in both PHP 5 and 7 is to modify the
code, despite the program being 100% correct under PHP 5 and the
documented semantics.
To re-iterate now that I've shared an example: code is broken whether
it's part of Exception or not. I would prefer to not break the code
for people who purposefully utilized the semantics of error handlers
and exceptions to write their valuable products. The people who didn't
actually intended to catch all Exceptions should be the ones who feel
the pain.
It's also the principle of least astonishment: why isn't TypeException
caught by catch (Exception $e)?
It's also the principle of least astonishment: why isn't TypeException
caught bycatch (Exception $e)?
This is probably a good argument in favour of "Error" as naming for engine exceptions. If you say "TypeError is not caught by catch (Exception $e)", it seems a lot less surprising. You can even say "a TypeError is Throwable, but it's not an Exception".
On a practical level, it's perfectly possible to write a handling function which can process all sorts of different user land exceptions, but wouldn't have a clue what to do about an engine error.
Regards,
Rowan Collins
[IMSoP]
On Sat, May 16, 2015 at 2:17 PM, Rowan Collins
rowan.collins@gmail.com wrote:The difference is that as time goes on and I've written code for PHP
7
I was hit by this issue. It's an even bigger issue than even I
realized during voting. How many people who voted on that issue have
played with the code from both scenarios? Few, I can't guarantee it
but given the historical precedent it's almost certainly true.Can you give an example of the issue you were hit with? A sample
program /
scenario, where failure to catch an EngineException caused behaviour
that
was in some way worse than that under PHP 5?Here's a simplified example that illustrates one issue:
<?php
set_error_handler(function(){
echo "Handled.";
});function foo(callable $f) {}
try {
foo("bar is not callable");
} catch (Exception $e) {
echo "Caught.";
}echo "Done.", PHP_EOL;
?>
In PHP 5 this prints "Handled.Done". Under PHP 7 this fails with:
Fatal error: Argument 1 passed to foo() must be callable, string
givenNote that if the TypeException had been caught by catch (Exception $e)
the program would have still been correct. This kind of setup exists
in PHPUnit for example; even if the test has some bad syntax or
failure the testing harness needs to continue. There are other valid
uses as well.
An interesting example. However, the behaviour would still have changed if TypeException was a sub-class of Exception, because it would echo "caught" rather than "handled" (a trivial difference in this trivial example, but there's no reason to assume the actual code would be the same in both cases).
The real problem here is that errors which were previously E_RECOVERABLE are now promoted to fatal when the exception is not caught. Unfortunately, I don't thick you can have both at once, because "recovering" an error returns control to wherever the error occurred, whereas an exception unwinds the stack looking for a matching catch block. So by the time an exception is flagged as uncaught, it's too late to make the error recoverable.
Of course, many of the instances of EngineException were never recoverable errors in PHP 5 (a few more would have changed that way had EngineExceptions not been adopted, e.g. https://wiki.php.net/rfc/catchable-call-to-member-of-non-object). Whichever way the hierarchy is arranged, the ability of PHPUnit to handle errors is improved, not diminished; however, it may require a one word change, under the currently accepted proposal.
Conversely, any code which handled E_RECOVERABLE but not exceptions, will now produce fatal errors, again regardless of the exception hierarchy implemented.
It's certainly a tricky issue, and the vote was far from unanimous, but I'm still not convinced of the case to reopen it.
Regards,
Rowan Collins
[IMSoP]
On Sat, May 16, 2015 at 2:17 PM, Rowan Collins
rowan.collins@gmail.com wrote:The difference is that as time goes on and I've written code for PHP
7
I was hit by this issue. It's an even bigger issue than even I
realized during voting. How many people who voted on that issue have
played with the code from both scenarios? Few, I can't guarantee it
but given the historical precedent it's almost certainly true.Can you give an example of the issue you were hit with? A sample
program /
scenario, where failure to catch an EngineException caused behaviour
that
was in some way worse than that under PHP 5?Here's a simplified example that illustrates one issue:
<?php
set_error_handler(function(){
echo "Handled.";
});function foo(callable $f) {}
try {
foo("bar is not callable");
} catch (Exception $e) {
echo "Caught.";
}echo "Done.", PHP_EOL;
?>
In PHP 5 this prints "Handled.Done". Under PHP 7 this fails with:
Fatal error: Argument 1 passed to foo() must be callable, string
givenNote that if the TypeException had been caught by catch (Exception $e)
the program would have still been correct. This kind of setup exists
in PHPUnit for example; even if the test has some bad syntax or
failure the testing harness needs to continue. There are other valid
uses as well.An interesting example. However, the behaviour would still have changed if TypeException was a sub-class of Exception, because it would echo "caught" rather than "handled" (a trivial difference in this trivial example, but there's no reason to assume the actual code would be the same in both cases).
Yes, it would have changed. As I have said several times now there is
a BC break no matter what we do here. My point is that since it's a BC
break no matter what we should trust that people who said catch (Exception) rather than assume that they didn't actually want to
catch all exceptions. They did, after all, write catch (Exception)
and exceptions are documented such that all exceptions must extend
Exception. We shouldn't assume that they didn't mean it and work
around it. For people who didn't mean it and they now get slapped:
that's good too because it forces them to change their logically
incorrect code. How is that a bad thing?
In this specific case we have broken all code out there. This is a
point that I am fairly sure people didn't fully understand in voting.
The idea that "we avoided a BC break by introducing a new exception
hierarchy" was simply untrue but that's essentially the idea they
voted on. Of course most people are going to vote to avoid BC break if
possible. This is why I think we certainly have grounds to revote.
In this specific case we have broken all code out there.
Yes, in the very specific case of people who both caught all exceptions and handled all E_RECOVERABLE errors, the existence of Throwable introduces a slightly worse BC break than without it.
For code that catches all exceptions but doesn't handle any errors (which seems perfectly reasonable to me), it improves BC, as they will catch only the same exceptions they already did.
It's also worth looking at the feature in its own right: if we didn't have any BC concerns, would it seem useful to be able to catch either all userland exceptions or all system exceptions, or both? If you were defining from scratch you could have UserException and EngineException extending Exception, but we can't change existing uses of Exception, so Exception and Error implementing Throwable gives us the same split.
Regards,
Rowan Collins
[IMSoP]
In this specific case we have broken all code out there.
Yes, in the very specific case of people who both caught all exceptions and handled all E_RECOVERABLE errors, the existence of Throwable introduces a slightly worse BC break than without it.
For code that catches all exceptions but doesn't handle any errors (which seems perfectly reasonable to me), it improves BC, as they will catch only the same exceptions they already did.
It's also worth looking at the feature in its own right: if we didn't have any BC concerns, would it seem useful to be able to catch either all userland exceptions or all system exceptions, or both? If you were defining from scratch you could have UserException and EngineException extending Exception, but we can't change existing uses of Exception, so Exception and Error implementing Throwable gives us the same split.
I'm not sure I would have separated them this way. I wouldn't group
TypeException in the same subtree as ParseException, for instance. One
happens at compile time and the other at run time, which means the
intent in what you catch is probably quite different.
I wouldn't group
TypeException in the same subtree as ParseException, for instance. One
happens at compile time and the other at run time, which means the
intent in what you catch is probably quite different.
TypeException is also different the other EngineExceptions, as it's an
exception that people will want to throw from their own code instead
of having a separate UserLandTypeException.
Except for testing, people shouldn't be throwing ParseException or
other EngineExceptions from their code.
cheers
Dan
Dan Ackroyd wrote on 18/05/2015 18:38:
I wouldn't group
TypeException in the same subtree as ParseException, for instance. One
happens at compile time and the other at run time, which means the
intent in what you catch is probably quite different.
TypeException is also different the other EngineExceptions, as it's an
exception that people will want to throw from their own code instead
of having a separate UserLandTypeException.Except for testing, people shouldn't be throwing ParseException or
other EngineExceptions from their code.
Hm, I think we may be getting somewhere; it does seem plausible that
some specific "catchable fatal errors" in PHP 5 should actually be
converted to Exceptions rather than Errors/EngineExceptions.
Indeed, some of them have closely-corresponding exception classes in
SPL, such as InvalidArgumentException:
Exception thrown if an argument is not of the expected type.
Thus the problem is not in creating an Exception/Error distinction in
the first place, but in not thinking about which cases belong on which
side of the split.
Regards,
Rowan Collins
[IMSoP]
Hi all,
On Sat, May 16, 2015 at 2:17 PM, Rowan Collins rowan.collins@gmail.com
wrote:The difference is that as time goes on and I've written code for PHP 7
I was hit by this issue. It's an even bigger issue than even I
realized during voting. How many people who voted on that issue have
played with the code from both scenarios? Few, I can't guarantee it
but given the historical precedent it's almost certainly true.Can you give an example of the issue you were hit with? A sample program
/
scenario, where failure to catch an EngineException caused behaviour that
was in some way worse than that under PHP 5?Here's a simplified example that illustrates one issue:
<?php
set_error_handler(function(){
echo "Handled.";
});function foo(callable $f) {}
try {
foo("bar is not callable");
} catch (Exception $e) {
echo "Caught.";
}echo "Done.", PHP_EOL;
?>
In PHP 5 this prints "Handled.Done". Under PHP 7 this fails with:
Fatal error: Argument 1 passed to foo() must be callable, string given
Note that if the TypeException had been caught by catch (Exception $e)
the program would have still been correct. This kind of setup exists
in PHPUnit for example; even if the test has some bad syntax or
failure the testing harness needs to continue. There are other valid
uses as well.The only way to make this work in both PHP 5 and 7 is to modify the
code, despite the program being 100% correct under PHP 5 and the
documented semantics.
We should consider internal function error/exception also.
New ZPP raises type error.
<?php
mt_srand('999999999999999999999999999');
mt_rand(0, 100);
?>
produces E_WARNING
Warning: mt_srand() expects parameter 1 to be integer, string given in - on
line 2
If we are going to break codes, it is better to break code consistently.
Is it possible treat each line enclosed by try {}? e.g.
<?php
try {
mt_srand('999999999999999999999999999');
} catch (WhateverException $e) {
// do something useful
}
try {
mt_rand(0, 100);
} catch (WhatEverException $e) {
// do something useful
}
?>
rather than
<?php
try {
mt_srand('999999999999999999999999999');
mt_rand(0, 100);
} catch (WhateverException $e) {
// do something useful
}
?>
For example,
set_exception_handler(callback $callback [, bool $single_line_try_block =
FALSE])
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
On Sat, May 16, 2015 at 12:28 PM, Stanislav Malyshev
smalyshev@gmail.com wrote:
Hi!
There's nothing that prevents us from reneging on that by another
vote. If it's a bad decision backed by logical arguments then we canThat's a pretty big if, given that your only argument - that it is a BC
break - is incorrect, as in fact the set of exceptions caught before and
after change is exactly the same, and the only difference is that in the
new code, you can also catch errors, the option that you didn't have
before. Absent that argument, there's no reason to renege.
You are incorrect. The set of exceptions that catch (Exception)
catches is all exceptions by its definition. By altering it to no
longer include all exceptions means the semantics of it changed.
On Sat, May 16, 2015 at 12:28 PM, Stanislav Malyshev
smalyshev@gmail.com wrote:Hi!
There's nothing that prevents us from reneging on that by another
vote. If it's a bad decision backed by logical arguments then we canThat's a pretty big if, given that your only argument - that it is a BC
break - is incorrect, as in fact the set of exceptions caught before and
after change is exactly the same, and the only difference is that in the
new code, you can also catch errors, the option that you didn't have
before. Absent that argument, there's no reason to renege.You are incorrect. The set of exceptions that
catch (Exception)
catches is all exceptions by its definition. By altering it to no
longer include all exceptions means the semantics of it changed.
From our manual (http://php.net/manual/en/language.exceptions.php):
The thrown object must be an instance of the Exception class or a subclass of Exception.
Hi!
The thrown object must be an instance of the Exception class or a subclass of Exception.
This is still true for objects that are thrown from userspace, AFAIK. If
not, we can make it true, I have no objection to it. This however gives
your no guarantee catch(Exception) catches everything that can happen
inside the code under catch.
Stas Malyshev
smalyshev@gmail.com
Hi!
You are incorrect. The set of exceptions that
catch (Exception)
catches is all exceptions by its definition. By altering it to no
There's no such definition. It's invented to serve your point, which
makes it circular logic. catch(Exception) catches everything that
descends from Exception. It is true that throwables that do not descend
from Exception did not exist before, however their exact semantics was
implemented as engine errors, so nothing changed in that regard.
catch(Exception) did not catch parse errors, it still doesn't.
longer include all exceptions means the semantics of it changed.
No, it doesn't mean that. It catches every exception descended from
class Exception as it did before. Nobody guaranteed you - and if fact it
never were true - that there are no other situations which can lead to
early exit from the code and that catch(Exception) can't catch. It is
still the case. Before, these things were implemented as "errors", now
some of them are implemented as exceptions. That's an implementation
detail, semantic hasn't changed - except for the fact that you can now
catch more of them is you wanted.
--
Stas Malyshev
smalyshev@gmail.com
On Sat, May 16, 2015 at 12:28 PM, Stanislav Malyshev
smalyshev@gmail.com wrote:Hi!
There's nothing that prevents us from reneging on that by another
vote. If it's a bad decision backed by logical arguments then we can
That's a pretty big if, given that your only argument - that it is a BC
break - is incorrect, as in fact the set of exceptions caught before and
after change is exactly the same, and the only difference is that in the
new code, you can also catch errors, the option that you didn't have
before. Absent that argument, there's no reason to renege.
You are incorrect. The set of exceptions thatcatch (Exception)
catches is all exceptions by its definition. By altering it to no
longer include all exceptions means the semantics of it changed.
Do you agree with these statements?
- There is no exception which a program using "catch ( Exception $e )"
will catch under PHP 5 but not under PHP 7 (with BaseException/Throwable
as proposed). - There is no fatal error which becomes non-fatal for such a program,
because they will become uncaught EngineExceptions, and failure to catch
an exception is a fatal error. - There is no non-fatal error which becomes fatal for such a program,
because EngineExceptions exist only where there were already fatal errors.
Leaving aside "definitions" and "semantics", where, then, is the BC break?
Regards,
--
Rowan Collins
[IMSoP]
Sebastian Bergmann wrote:
I am sorry that I was unable to raise this concern earlier (did not
really become aware of the RFC before it was put to the vote), but I
would prefer the following:
- Introduce a Throwable interface
- Let Exception implement the Throwable interface
- Introduce an Error class that implements the Throwable interface
- Use Error class as base class for exceptions raised by the engine
This would be along the lines of what Java does.
Note, that a Throwable interface has been already brought up a while ago[1].
[1] http://news.php.net/php.internals/83207
--
Christoph M. Becker
+1000 on this; so much better than the BaseException stuff!
Am 23.02.2015 um 19:15 schrieb Nikita Popov:
Voting on the engine exceptions RFC, which proposes to convert existing
fatal and recoverable fatal errors into exceptions, has opened:https://wiki.php.net/rfc/engine_exceptions_for_php7#vote
The primary vote requires a 2/3 majority, as this is a language change.
A second vote will decide whether to use a BaseException based inheritance
hierarchy. This vote uses a simple majority.I have voted yes on "Allow exceptions in the engine and conversion of
existing fatals?" and no on "Introduce and use BaseException?" and
would like to elaborate on the latter.I am sorry that I was unable to raise this concern earlier (did not
really become aware of the RFC before it was put to the vote), but I
would prefer the following:
- Introduce a Throwable interface
- Let Exception implement the Throwable interface
- Introduce an Error class that implements the Throwable interface
- Use Error class as base class for exceptions raised by the engine
This would be along the lines of what Java does.
Le 23/02/2015 19:15, Nikita Popov a écrit :
Voting on the engine exceptions RFC, which proposes to convert existing
fatal and recoverable fatal errors into exceptions, has opened:https://wiki.php.net/rfc/engine_exceptions_for_php7#vote
Hi,
After discussing the main proposition of this RFC with other people at
AFUP, it appears we would be +1 (by a large margin !).
Thanks for your work!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
Am 23.02.2015 um 19:15 schrieb Nikita Popov:
Voting is open until 2015-03-08.
Voting ends today and it looks like the RFC will be accepted. How
should we proceed with regards to the comments I made in
Message-ID: 54F07FC7.8050901@php.net
Date: Fri, 27 Feb 2015 15:31:35 +0100
Guilherme volunteered to create a new RFC for the Throwable interface
immediately after this RFC is accepted. Sounds good to me :-)
Hi!
Message-ID: 54F07FC7.8050901@php.net
Date: Fri, 27 Feb 2015 15:31:35 +0100Guilherme volunteered to create a new RFC for the Throwable interface
immediately after this RFC is accepted. Sounds good to me :-)
I would say create the RFC :) Nothing says we should immediately rush
with implementing it in exactly the same form as the RFC says and can't
modify it - if throwable looks better, and there's a better solution
using it, we could hold a bit for this one to be accepted I think.
--
Stas Malyshev
smalyshev@gmail.com
Hi internals!
Voting on the engine exceptions RFC, which proposes to convert existing
fatal and recoverable fatal errors into exceptions, has opened:https://wiki.php.net/rfc/engine_exceptions_for_php7#voteThe primary vote requires a 2/3 majority, as this is a language change.
A second vote will decide whether to use a BaseException based inheritance
hierarchy. This vote uses a simple majority.Voting is open until 2015-03-08.
This RFC has been accepted with 60 votes in favor and 2 against. The
BaseException hierarchy has been accepted with 39 in favor and 19 against.
During voting some concerns about the naming of the BaseException class
have been raised. This detail can be sorted out in a follow-up discussion -
changing this (assuming only the name is changed) is simple and only a
couple of tests need to be adjusted.
Dmitry, do you want to merge your current patch?
Nikita
Why not wait with the merge until a consensus emerges regarding Throwable?
Hi internals!
Voting on the engine exceptions RFC, which proposes to convert existing
fatal and recoverable fatal errors into exceptions, has opened:https://wiki.php.net/rfc/engine_exceptions_for_php7#vote
The primary vote requires a 2/3 majority, as this is a language change.
A second vote will decide whether to use a BaseException based inheritance
hierarchy. This vote uses a simple majority.Voting is open until 2015-03-08.
This RFC has been accepted with 60 votes in favor and 2 against. The
BaseException hierarchy has been accepted with 39 in favor and 19 against.During voting some concerns about the naming of the BaseException class
have been raised. This detail can be sorted out in a follow-up discussion -
changing this (assuming only the name is changed) is simple and only a
couple of tests need to be adjusted.Dmitry, do you want to merge your current patch?
Nikita
Am 09.03.2015 um 12:04 schrieb David Zuelke dz@heroku.com:
Why not wait with the merge until a consensus emerges regarding Throwable?
Hi internals!
Voting on the engine exceptions RFC, which proposes to convert existing
fatal and recoverable fatal errors into exceptions, has opened:https://wiki.php.net/rfc/engine_exceptions_for_php7#vote
The primary vote requires a 2/3 majority, as this is a language change.
A second vote will decide whether to use a BaseException based inheritance
hierarchy. This vote uses a simple majority.Voting is open until 2015-03-08.
This RFC has been accepted with 60 votes in favor and 2 against. The
BaseException hierarchy has been accepted with 39 in favor and 19 against.During voting some concerns about the naming of the BaseException class
have been raised. This detail can be sorted out in a follow-up discussion -
changing this (assuming only the name is changed) is simple and only a
couple of tests need to be adjusted.Dmitry, do you want to merge your current patch?
Nikita
I'd like to merge master in and finish my patches to use the EngineException too.
Also, what's the reason to delay it? The RFC only should be a tiny commit to rename and change from abstract class to interface. Whose voting will finish not before beginning of April...
Nothing significant will be changed (simple find&replace, that's probably all), but it's easier to adapt, when the changes are in earlier.
I just can repeat Nikita: Please merge it, Dmitry.
Thanks,
Bob
Why not wait with the merge until a consensus emerges regarding Throwable?
The patch for engine exceptions is large - the longer that it is left
unmerged, the more difficult it will be to do and people's time is
valuable. It also delays finding bugs or other issues in the engine
exception patch by at least two weeks, which is about 15% of the time
until we're meant to be having an RC.
Any change in the exception hierarchy or use of interfaces should be a
small patch. Holding off on merging the engine exception patch doesn't
make it significantly easier to do.
So even though I hope we can clean up the exception hierarchy, merging
the engine exceptions is the right choice imo.
cheers
Dan
Am 09.03.2015 um 12:40 schrieb Dan Ackroyd:
So even though I hope we can clean up the exception hierarchy, merging
the engine exceptions is the right choice imo.
Sounds reasonable to me. I'm wondering, though, whether we really need
an additional RFC for the change I suggested as nobody spoke out against
it and several were in favor.
On Mon, Feb 23, 2015 at 7:15 PM, Nikita Popov nikita.ppv@gmail.com
wrote:Hi internals!
Voting on the engine exceptions RFC, which proposes to convert existing
fatal and recoverable fatal errors into exceptions, has opened:https://wiki.php.net/rfc/engine_exceptions_for_php7#voteThe primary vote requires a 2/3 majority, as this is a language change.
A second vote will decide whether to use a BaseException based
inheritance hierarchy. This vote uses a simple majority.Voting is open until 2015-03-08.
This RFC has been accepted with 60 votes in favor and 2 against. The
BaseException hierarchy has been accepted with 39 in favor and 19 against.During voting some concerns about the naming of the BaseException class
have been raised. This detail can be sorted out in a follow-up discussion -
changing this (assuming only the name is changed) is simple and only a
couple of tests need to be adjusted.Dmitry, do you want to merge your current patch?
Hi,
Yes, I would prefer to merge it, because the patch is big and keeping it in
synch with master is additional overhead. Also we will able to start
converting more errors to exceptions. Please merge (I don't work today).
On the other hand, I'm agree that using Throwable interface may make sense.
If we have implementation and short RFC, I think we may start voting
immediately, because it was already discussed together with this RFC.
Thanks. Dmitry.
Nikita