Re: [PHP-DEV] [VOTE] Exceptions in the engine
Hi all,
On Sun, May 17, 2015 at 8:44 AM, Levi Morrison le...@php.net wrote:
On Sat, May 16, 2015 at 2:17 PM, Rowan Collins rowan.coll...@gmail.com
wrote:
On 16/05/2015 20:15, Levi Morrison 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('999');
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('999');
} catch (WhateverException $e) {
// do something useful
}
try {
mt_rand(0, 100);
} catch (WhatEverException $e) {
// do something useful
}
?
rather than
?php
try {
mt_srand('999');
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
yohg...@ohgaki.net
Re: [PHP-DEV] [VOTE] Exceptions in the engine
Dan Ackroyd wrote on 18/05/2015 18:38: On 18 May 2015 at 15:39, Levi Morrison le...@php.net wrote: 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] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
On Sun, May 17, 2015 at 11:44 AM, Rowan Collins rowan.coll...@gmail.com wrote: On 17 May 2015 16:02:40 BST, Levi Morrison le...@php.net wrote: 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
On Sun, May 17, 2015 at 7:10 AM, Rowan Collins rowan.coll...@gmail.com wrote:
On 17 May 2015 00:44:03 BST, Levi Morrison le...@php.net wrote:
On Sat, May 16, 2015 at 2:17 PM, Rowan Collins
rowan.coll...@gmail.com wrote:
On 16/05/2015 20:15, Levi Morrison 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.
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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
On 17 May 2015 16:02:40 BST, Levi Morrison le...@php.net wrote: 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] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
On 17 May 2015 00:44:03 BST, Levi Morrison le...@php.net wrote:
On Sat, May 16, 2015 at 2:17 PM, Rowan Collins
rowan.coll...@gmail.com wrote:
On 16/05/2015 20:15, Levi Morrison 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.
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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
On Sat, May 16, 2015 at 11:51 AM, Levi Morrison le...@php.net wrote: 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
On 16/05/2015 20:15, Levi Morrison 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? Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
On Sat, May 16, 2015 at 12:28 PM, Stanislav Malyshev smalys...@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. 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
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 smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
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 smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
On Sat, May 16, 2015 at 12:28 PM, Stanislav Malyshev smalys...@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 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
On Sat, May 16, 2015 at 12:44 PM, Levi Morrison le...@php.net wrote: On Sat, May 16, 2015 at 12:28 PM, Stanislav Malyshev smalys...@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 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
On 16/05/2015 19:44, Levi Morrison wrote: On Sat, May 16, 2015 at 12:28 PM, Stanislav Malyshev smalys...@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 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. 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] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
On 16/05/2015 15:40, Levi Morrison wrote:
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 and*do 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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
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 smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
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 smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
On Sat, May 16, 2015 at 1:13 PM, Stanislav Malyshev smalys...@gmail.com wrote: 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
On Sat, May 16, 2015 at 2:17 PM, Rowan Collins rowan.coll...@gmail.com wrote:
On 16/05/2015 20:15, Levi Morrison 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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
On Sat, May 16, 2015 at 5:44 PM, Levi Morrison le...@php.net wrote:
On Sat, May 16, 2015 at 2:17 PM, Rowan Collins rowan.coll...@gmail.com
wrote:
On 16/05/2015 20:15, Levi Morrison 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.
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)`?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
On Wed, May 13, 2015 at 9:38 AM, Sebastian Bergmann sebast...@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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
On Wed, May 13, 2015 at 9:38 AM, Sebastian Bergmann sebast...@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
Re: [PHP-DEV] [VOTE] Exceptions in the engine
On May 13, 2015 12:43 PM, Sebastian Bergmann sebast...@php.net wrote: 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 :)
Re: [PHP-DEV] [VOTE] Exceptions in the engine
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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
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! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
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 smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
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 ;) On 30.04.2015, at 18:51, Stanislav Malyshev smalys...@gmail.com wrote: 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 smalys...@gmail.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] [VOTE] Exceptions in the engine
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! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
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 smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
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? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
On Fri, May 1, 2015 at 1:04 PM, Sebastian Bergmann sebast...@php.net wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
Am 30.04.2015 um 14:30 schrieb Julien Pauli: On Thu, Apr 30, 2015 at 6:51 AM, Sebastian Bergmann sebast...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
On Thu, Apr 30, 2015 at 6:51 AM, Sebastian Bergmann sebast...@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. Julien.Pauli
Re: [PHP-DEV] [VOTE] Exceptions in the engine
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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
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 smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
Hi Stas, 2015-04-30 13:51 GMT-03:00 Stanislav Malyshev smalys...@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 smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php 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.
Re: [PHP-DEV] [VOTE] Exceptions in the engine
On May 1, 2015 1:24 AM, Marcio Almada marcio.w...@gmail.com wrote: Hi Stas, 2015-04-30 13:51 GMT-03:00 Stanislav Malyshev smalys...@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 smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php 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.
Re: [PHP-DEV] [VOTE] Exceptions in the engine
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
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 smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
Hi Sebastian, On Sun, Mar 22, 2015 at 2:05 AM, Sebastian Bergmann sebast...@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/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? 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 yohg...@ohgaki.net
Re: [PHP-DEV] [VOTE] Exceptions in the engine
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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
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? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
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 ? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
On Sun, Mar 15, 2015 at 8:27 AM, Sebastian Bergmann sebast...@php.net wrote: 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
On 9 March 2015 at 11:04, David Zuelke d...@heroku.com wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
Am 09.03.2015 um 12:04 schrieb David Zuelke d...@heroku.com: Why not wait with the merge until a consensus emerges regarding Throwable? On 09.03.2015, at 05:26, Nikita Popov nikita@gmail.com wrote: On Mon, Feb 23, 2015 at 7:15 PM, Nikita Popov nikita@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#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 findreplace, 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
Why not wait with the merge until a consensus emerges regarding Throwable? On 09.03.2015, at 05:26, Nikita Popov nikita@gmail.com wrote: On Mon, Feb 23, 2015 at 7:15 PM, Nikita Popov nikita@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#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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
Hi! Message-ID: 54f07fc7.8050...@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 :-) 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 smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
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.8050...@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 :-) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
+1000 on this; so much better than the BaseException stuff! On 27.02.2015, at 15:31, Sebastian Bergmann sebast...@php.net wrote: 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. -- 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] [VOTE] Exceptions in the engine
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. On Fri, Feb 27, 2015 at 5:47 PM, Jordi Boggiano j.boggi...@seld.be wrote: On 27/02/2015 14:31, Sebastian Bergmann wrote: 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. +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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
On 27/02/2015 14:31, Sebastian Bergmann wrote: 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. +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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
+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, On Fri, Feb 27, 2015 at 9:47 AM, Jordi Boggiano j.boggi...@seld.be wrote: On 27/02/2015 14:31, Sebastian Bergmann wrote: 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. +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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Guilherme Blanco MSN: guilhermebla...@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada
Re: [PHP-DEV] [VOTE] Exceptions in the engine
On 2/27/15 9:28 AM, guilhermebla...@gmail.com wrote: +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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
Hi all, On Tue, Feb 24, 2015 at 4:28 PM, Pavel Kouřil pajou...@gmail.com wrote: 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 yohg...@ohgaki.net
Re: [PHP-DEV] [VOTE] Exceptions in the engine
Hi all, On Tue, Feb 24, 2015 at 8:04 PM, Dennis Birkholz den...@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=phpq=baseexceptiontype=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=phpq=abstractexceptionref=searchresultstype=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 yohg...@ohgaki.net
Re: [PHP-DEV] [VOTE] Exceptions in the engine
2015-02-24 13:29 GMT+01:00 Yasuo Ohgaki yohg...@ohgaki.net: Hi all, On Tue, Feb 24, 2015 at 8:04 PM, Dennis Birkholz den...@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=phpq=baseexceptiontype=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=phpq=abstractexceptionref=searchresultstype=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.
Re: [PHP-DEV] [VOTE] Exceptions in the engine
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=phpq=baseexceptiontype=Code finds about 14k matches, so this may be a huge BC break if the actual class name is not changed. Thanks Dennis -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Exceptions in the engine
Hi Nikita, On Tue, Feb 24, 2015 at 3:15 AM, Nikita Popov nikita@gmail.com wrote: 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. 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 yohg...@ohgaki.net
Re: [PHP-DEV] [VOTE] Exceptions in the engine
On Tue, Feb 24, 2015 at 12:03 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Nikita, On Tue, Feb 24, 2015 at 3:15 AM, Nikita Popov nikita@gmail.com wrote: 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. 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 yohg...@ohgaki.net Hello, I personally find both BaseException and AbstractException ugly. The Throwable is IMHO much better. Regards Pavel Kouril -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
