Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7
On Sat, Aug 22, 2015 at 2:10 AM, Anatol Belski anatol@belski.net wrote: Hi, -Original Message- From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Friday, August 21, 2015 3:37 PM To: Scott Arciszewski sc...@paragonie.com Cc: Pierre Joye pierre@gmail.com; Trevor Suarez ric...@gmail.com ; Niklas Keller m...@kelunik.com; PHP Internals internals@lists.php.net Subject: Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7 On Fri, Aug 21, 2015 at 6:14 AM, Scott Arciszewski sc...@paragonie.com wrote: On Fri, Aug 21, 2015 at 3:52 AM, Pierre Joye pierre@gmail.com wrote: On Fri, Aug 21, 2015 at 9:38 AM, Scott Arciszewski sc...@paragonie.com wrote: On Wed, Aug 19, 2015 at 11:36 AM, Trevor Suarez ric...@gmail.com wrote: Ah, I didn't realize this thread existed. I had just commented on the old one, but the point still stands: PHP 7.0 RC1 was just tagged. Shouldn't this be a relatively high priority to fix/decide so we don't end up with behavior that can't be fixed until PHP 8.0? On Mon, Aug 10, 2015 at 6:54 PM Niklas Keller m...@kelunik.com wrote: Okay, great, we have people on both sides on this discussion. I hope nobody minds if I sit this part out. What specifics need to be discussed? Should somebody set up a poll? (I don't know how to do that.) You can find information on how to setup a poll in step 6 here: https://wiki.php.net/rfc/howto Regards, Niklas I agree that this should be a relatively high priority. I'm not sure what the next steps would be. (Aside: I still have a PR I need to write that I've been holding off on until the fate of PHP 7's CSPRNG feature is determined.) Can we reach some sort of consensus on throw new Exception vs throw new Error? I think the best would be a RFC, not only for the decision itself but also to have a clear view about what will be changed or affected. Cheers, -- Pierre @pierrejoye | http://www.libgd.org Fine, let's do this: 1. Violate the feature freeze for this exceptional decision. 2. One of the folks in the camp that WANTS an RFC and a drawn out formal decision-making process opens it with a poll. 3. Give me voting karma. Let's NOT make the CSPRNG feature fail open. That is an absolutely terrible idea. My proposal/stance: Let's make random_* throw an Exception if it cannot connect to a random source. And let's have it throw an TypeError if ZPP fails, or Error if min = max. The first two are consistent with existing exceptions. The third (Error if minmax) is where the contention lies. I'm suggesting Error as it's consistent with parameter errors in the sense that the type may be correct, but the value isn't (hence it's the same kind of error as a parameter error, just a different sub-classification. MHO is this is too important of a distinction to simply gloss over. Having it return false (or null) will be a problem, as nobody will perform the error checks. And returning $x where `$x == 0` in a security context could be incredibly bad. As such, I think the security implications here outweigh nearly all of the other concerns about consistency and convention. That's my opinion. I'll be happy to make the changes if a RM gives me the green light to do so. The change being proposed was discussed once more in the RM circle and is being seen as inappropriate. The CSPRNG RFC and the implementation was voted. The change being proposed amends the paradigm of the current language behavior. Currently no effort has been done do discuss and work out the paradigm change. There has been quite extensive discussion on this topic. Apart from 30 comments on the original PR for this, there are 100 mails across three topics discussing this issue. As far as I can discern, there was a rather clear consensus in these discussions to make the error conditions throw (although this may be confirmation bias speaking). The only point of contention that was left towards the end of the discussion, was which exception specifically should be thrown in one of the cases. This was a bikeshedding concern. All the people who participated in the Exception vs. Error discussion are okay with either choice here, with mild preferences going in different directions. You could flip a coin and nobody would complain about the result. Nobody really cares whether this exception is green or blue. I'm honestly surprised at this decision. I had assumed that the question of whether we throw was already a done matter and we're only talking about the exception type at this point. Nikita
Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7
On 22.08.2015 at 03:02, Pierre Joye wrote: On Aug 22, 2015 7:39 AM, Christoph Becker cmbecke...@gmx.de wrote: On 21.08.2015 at 12:14, Scott Arciszewski wrote: 2. One of the folks in the camp that WANTS an RFC and a drawn out formal decision-making process opens it with a poll. AIUI, that is not how it is supposed to work. Those who want to change existing behavior should make a respective RFC, if consensus couldn't be reached otherwise. Do you mean a change like this can be applied without rfc? If yes, I disagree. I was not particularly referring to the issue at hand, but rather made a general statement. In this case (core functions throwing exceptions) obviously there is no consensus, so an RFC would be appropriate. -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7
Hi Anthony, -Original Message- From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Saturday, August 22, 2015 4:44 AM To: Pierre Joye pierre@gmail.com Cc: Anatol Belski anatol@belski.net; Scott Arciszewski sc...@paragonie.com; Niklas Keller m...@kelunik.com; Trevor Suarez ric...@gmail.com; PHP internals internals@lists.php.net Subject: Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7 Pierre On Aug 21, 2015 22:33, Pierre Joye pierre@gmail.com wrote: On Sat, Aug 22, 2015 at 9:16 AM, Anthony Ferrara ircmax...@gmail.com wrote: If that's what it will take I will happily draft one tomorrow morning. But if the RMs are against it, I will respect that as well. Hence the dilemma. For what I understand the RMs are not against what it is proposed but its incompleteness and the fact that it affects the timeline for php 7. The sooner will benefit from a RFC, making this whole discussion a lot clearer. The latter is a requirement to change, even slightly, anything about what we decided for php 7. The RMs role is to ensure we respect what we decided by RFC, hence the oppositions. By convention, it is also to decide which rfcs are applicable for a specific release. I would like to respect that. If they say no, I won't waste time and energy on the rfc process as it will be pointless as it won't affect 7.0. If they say yes, then we can make it quick and as painless as possible and settle it once and for all. It bothers me though that it has to come down to this. But that's another discussion for another day. Thanks for your constructive responses and deferential conduct. Looking retrospectively t the RFC votes closing days noted in the wiki - engine exceptions on March 8th - CSPRNG on March 28th - Throwable on June 17th the engine exceptions and CSPRNG lay quite near in time, so it is obvious CSPRNG implementation couldn't have been changed short before or after the other one as they cross each other so close in time. A notable fact also is that quite a new stuff in Throwable was taken already after release circle start and the point of no accept for the new RFCs. In any case, by the times so much of new functionality was clearly overmuch to digest. And it is still even more of discovery for people not having PHP7 experiences. For what it matters, a suggestion about a need on a strategy with this matter sounded in the early days of this discussion. Unfortunately it was not taken seriously, which is sad as well. The exact goal of calling for RFC already at that time was to bring all the bike shedding onto a productive path and to avoid a situation like it is now. Actually this argument is nothing else than bike shedding on the times and mindsets, so were not worth to mention. But having not the 1.5 month time lost, we probably wouldn't stand where we stand now. From what all the bike shedding crystalized, there are at least three main directions to see, when it comes to throw in functions. Please correct me when I'm wrong - security aspect (this discussion) - conversion of fatal errors (touched partially in a PR by Aaron) - ZPP handling (mentioned by Nikita) These look like they can be handled separately, what they have in common is - definition of Error and Exception use case - further development of the exception hierarchy Please don't catch me on the above, it is only what could be marked by my mind from the discussions. From these, either there can be an RFC with a proper solution of one or all the topics spliced with the possible delay of the PHP7 final awareness, or there can be an RFC to include a partial solution being pushed so far and possible inconsistency consequences, or CSPRNG functionality can be deferred until a complete solution, or CSPRNG can be reimplemented as class where exceptions belong to the natural flow, or a good sustainable solution can be offered in 7.1. Any other ideas. From the time line - there are five release slots until final yet. Were it an RFC which is accepted, the change would land in RC3 most likely, that would mean there were yet three release slots till final. Under the condition that the current timeline is held. From the last stand point discussed with the other RMs, as they seem not to be reachable for a direct discussion most of today - such a change affects long term features and language paradigm, which is the matter of the community competence. There's the 7.0 timeline which is a voted thing, there is a release process document which defines that the votes take place on RFCs directly and not on the mailing lists. The RMs belief is that the suggested change is the exact kind of needing a collective decision. Due to the concerns explained earlier, the timeline RFC and other items seem to be in clash with the change how it is proposed ATM. To undo/change any of those items to pass the suggested change in, another RFC seems
RE: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7
Anthony, -Original Message- From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Saturday, August 22, 2015 5:55 PM To: Anatol Belski anatol@belski.net Cc: Pierre Joye pierre@gmail.com; Scott Arciszewski sc...@paragonie.com; Niklas Keller m...@kelunik.com; Trevor Suarez ric...@gmail.com; PHP internals internals@lists.php.net Subject: Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7 From what it sounds like, you wouldn't be opposed to an RFC for getting it into 7.0. Is that what I understood? If so, we'll have something in draft today. Thanks for the clarity! Thanks for taking the RMs suggestions into account and for going the effort of the RFC. Godspeed! Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7
Hi Nikita, -Original Message- From: Nikita Popov [mailto:nikita@gmail.com] Sent: Saturday, August 22, 2015 12:17 PM To: Anatol Belski anatol@belski.net Cc: Anthony Ferrara ircmax...@gmail.com; Scott Arciszewski sc...@paragonie.com; Pierre Joye pierre@gmail.com; Trevor Suarez ric...@gmail.com; Niklas Keller m...@kelunik.com; PHP Internals internals@lists.php.net Subject: Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7 There has been quite extensive discussion on this topic. Apart from 30 comments on the original PR for this, there are 100 mails across three topics discussing this issue. As far as I can discern, there was a rather clear consensus in these discussions to make the error conditions throw (although this may be confirmation bias speaking). The only point of contention that was left towards the end of the discussion, was which exception specifically should be thrown in one of the cases. This was a bikeshedding concern. All the people who participated in the Exception vs. Error discussion are okay with either choice here, with mild preferences going in different directions. You could flip a coin and nobody would complain about the result. Nobody really cares whether this exception is green or blue. I'm honestly surprised at this decision. I had assumed that the question of whether we throw was already a done matter and we're only talking about the exception type at this point. No exact counting, but on github and ML there were probably not more than 20 participants. To compare, alone on the CSPRNG voting 41 persons took part. What is happening is that the exceptions snow ball starts to roll, the commendation to have an RFC was expressed earlier and is merely a measure to ensure everyone is involved and the snow ball doesn't turn into a snow bank at the end. Hopefully the escalation happened lately is good for seeing possible consequences to take shape. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7
Anatol, On Sat, Aug 22, 2015 at 10:34 AM, Anatol Belski anatol@belski.net wrote: Hi Anthony, -Original Message- From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Saturday, August 22, 2015 4:44 AM To: Pierre Joye pierre@gmail.com Cc: Anatol Belski anatol@belski.net; Scott Arciszewski sc...@paragonie.com; Niklas Keller m...@kelunik.com; Trevor Suarez ric...@gmail.com; PHP internals internals@lists.php.net Subject: Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7 Pierre On Aug 21, 2015 22:33, Pierre Joye pierre@gmail.com wrote: On Sat, Aug 22, 2015 at 9:16 AM, Anthony Ferrara ircmax...@gmail.com wrote: If that's what it will take I will happily draft one tomorrow morning. But if the RMs are against it, I will respect that as well. Hence the dilemma. For what I understand the RMs are not against what it is proposed but its incompleteness and the fact that it affects the timeline for php 7. The sooner will benefit from a RFC, making this whole discussion a lot clearer. The latter is a requirement to change, even slightly, anything about what we decided for php 7. The RMs role is to ensure we respect what we decided by RFC, hence the oppositions. By convention, it is also to decide which rfcs are applicable for a specific release. I would like to respect that. If they say no, I won't waste time and energy on the rfc process as it will be pointless as it won't affect 7.0. If they say yes, then we can make it quick and as painless as possible and settle it once and for all. It bothers me though that it has to come down to this. But that's another discussion for another day. Thanks for your constructive responses and deferential conduct. Looking retrospectively t the RFC votes closing days noted in the wiki - engine exceptions on March 8th - CSPRNG on March 28th - Throwable on June 17th the engine exceptions and CSPRNG lay quite near in time, so it is obvious CSPRNG implementation couldn't have been changed short before or after the other one as they cross each other so close in time. A notable fact also is that quite a new stuff in Throwable was taken already after release circle start and the point of no accept for the new RFCs. In any case, by the times so much of new functionality was clearly overmuch to digest. And it is still even more of discovery for people not having PHP7 experiences. For what it matters, a suggestion about a need on a strategy with this matter sounded in the early days of this discussion. Unfortunately it was not taken seriously, which is sad as well. The exact goal of calling for RFC already at that time was to bring all the bike shedding onto a productive path and to avoid a situation like it is now. Actually this argument is nothing else than bike shedding on the times and mindsets, so were not worth to mention. But having not the 1.5 month time lost, we probably wouldn't stand where we stand now. From what all the bike shedding crystalized, there are at least three main directions to see, when it comes to throw in functions. Please correct me when I'm wrong - security aspect (this discussion) - conversion of fatal errors (touched partially in a PR by Aaron) - ZPP handling (mentioned by Nikita) These look like they can be handled separately, what they have in common is - definition of Error and Exception use case - further development of the exception hierarchy Please don't catch me on the above, it is only what could be marked by my mind from the discussions. From these, either there can be an RFC with a proper solution of one or all the topics spliced with the possible delay of the PHP7 final awareness, or there can be an RFC to include a partial solution being pushed so far and possible inconsistency consequences, or CSPRNG functionality can be deferred until a complete solution, or CSPRNG can be reimplemented as class where exceptions belong to the natural flow, or a good sustainable solution can be offered in 7.1. Any other ideas. From the time line - there are five release slots until final yet. Were it an RFC which is accepted, the change would land in RC3 most likely, that would mean there were yet three release slots till final. Under the condition that the current timeline is held. From the last stand point discussed with the other RMs, as they seem not to be reachable for a direct discussion most of today - such a change affects long term features and language paradigm, which is the matter of the community competence. There's the 7.0 timeline which is a voted thing, there is a release process document which defines that the votes take place on RFCs directly and not on the mailing lists. The RMs belief is that the suggested change is the exact kind of needing a collective decision. Due to the concerns explained earlier, the timeline RFC and other items seem to be in clash
Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7
Pierre On Aug 21, 2015 22:33, Pierre Joye pierre@gmail.com wrote: On Sat, Aug 22, 2015 at 9:16 AM, Anthony Ferrara ircmax...@gmail.com wrote: If that's what it will take I will happily draft one tomorrow morning. But if the RMs are against it, I will respect that as well. Hence the dilemma. For what I understand the RMs are not against what it is proposed but its incompleteness and the fact that it affects the timeline for php 7. The sooner will benefit from a RFC, making this whole discussion a lot clearer. The latter is a requirement to change, even slightly, anything about what we decided for php 7. The RMs role is to ensure we respect what we decided by RFC, hence the oppositions. By convention, it is also to decide which rfcs are applicable for a specific release. I would like to respect that. If they say no, I won't waste time and energy on the rfc process as it will be pointless as it won't affect 7.0. If they say yes, then we can make it quick and as painless as possible and settle it once and for all. It bothers me though that it has to come down to this. But that's another discussion for another day. Anthony
Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7
On Fri, Aug 21, 2015 at 10:16 PM, Anthony Ferrara ircmax...@gmail.com wrote: Pierre On Aug 21, 2015 22:01, Pierre Joye pierre@gmail.com wrote: On Sat, Aug 22, 2015 at 8:43 AM, Anthony Ferrara ircmax...@gmail.com wrote: Anatol, On Aug 21, 2015 8:10 PM, Anatol Belski anatol@belski.net wrote: Hi, -Original Message- From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Friday, August 21, 2015 3:37 PM To: Scott Arciszewski sc...@paragonie.com Cc: Pierre Joye pierre@gmail.com; Trevor Suarez ric...@gmail.com; Niklas Keller m...@kelunik.com; PHP Internals internals@lists.php.net Subject: Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7 On Fri, Aug 21, 2015 at 6:14 AM, Scott Arciszewski sc...@paragonie.com wrote: On Fri, Aug 21, 2015 at 3:52 AM, Pierre Joye pierre@gmail.com wrote: On Fri, Aug 21, 2015 at 9:38 AM, Scott Arciszewski sc...@paragonie.com wrote: On Wed, Aug 19, 2015 at 11:36 AM, Trevor Suarez ric...@gmail.com wrote: Ah, I didn't realize this thread existed. I had just commented on the old one, but the point still stands: PHP 7.0 RC1 was just tagged. Shouldn't this be a relatively high priority to fix/decide so we don't end up with behavior that can't be fixed until PHP 8.0? On Mon, Aug 10, 2015 at 6:54 PM Niklas Keller m...@kelunik.com wrote: Okay, great, we have people on both sides on this discussion. I hope nobody minds if I sit this part out. What specifics need to be discussed? Should somebody set up a poll? (I don't know how to do that.) You can find information on how to setup a poll in step 6 here: https://wiki.php.net/rfc/howto Regards, Niklas I agree that this should be a relatively high priority. I'm not sure what the next steps would be. (Aside: I still have a PR I need to write that I've been holding off on until the fate of PHP 7's CSPRNG feature is determined.) Can we reach some sort of consensus on throw new Exception vs throw new Error? I think the best would be a RFC, not only for the decision itself but also to have a clear view about what will be changed or affected. Cheers, -- Pierre @pierrejoye | http://www.libgd.org Fine, let's do this: 1. Violate the feature freeze for this exceptional decision. 2. One of the folks in the camp that WANTS an RFC and a drawn out formal decision-making process opens it with a poll. 3. Give me voting karma. Let's NOT make the CSPRNG feature fail open. That is an absolutely terrible idea. My proposal/stance: Let's make random_* throw an Exception if it cannot connect to a random source. And let's have it throw an TypeError if ZPP fails, or Error if min = max. The first two are consistent with existing exceptions. The third (Error if minmax) is where the contention lies. I'm suggesting Error as it's consistent with parameter errors in the sense that the type may be correct, but the value isn't (hence it's the same kind of error as a parameter error, just a different sub-classification. MHO is this is too important of a distinction to simply gloss over. Having it return false (or null) will be a problem, as nobody will perform the error checks. And returning $x where `$x == 0` in a security context could be incredibly bad. As such, I think the security implications here outweigh nearly all of the other concerns about consistency and convention. That's my opinion. I'll be happy to make the changes if a RM gives me the green light to do so. The change being proposed was discussed once more in the RM circle and is being seen as inappropriate. The CSPRNG RFC and the implementation was voted. The change being proposed amends the paradigm of the current language behavior. Currently no effort has been done do discuss and work out the paradigm change. By today's terms, there are other functions which could require throwing instead of returning false for security reasons. Security being over BC was and is even in the patch versions, however how it is handled is related to the hard and deeply internal cases like memory corruption, etc. Having a decision that a return value is something security related has impact to the existing behavior. Having different technical requirements to the congeneric cases on the language level brings inconsistency. Producing inconsistent behaviors by one case, without any evaluation and clear course for other cases, without respecting the votes and code freeze is alarming. The current timeline doesn't allow
Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7
On Sat, Aug 22, 2015 at 9:16 AM, Anthony Ferrara ircmax...@gmail.com wrote: If that's what it will take I will happily draft one tomorrow morning. But if the RMs are against it, I will respect that as well. Hence the dilemma. For what I understand the RMs are not against what it is proposed but its incompleteness and the fact that it affects the timeline for php 7. The sooner will benefit from a RFC, making this whole discussion a lot clearer. The latter is a requirement to change, even slightly, anything about what we decided for php 7. The RMs role is to ensure we respect what we decided by RFC, hence the oppositions. 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] Recap - Core functions throwing exceptions in PHP7
On Aug 22, 2015 9:33 AM, Pierre Joye pierre@gmail.com wrote: On Sat, Aug 22, 2015 at 9:16 AM, Anthony Ferrara ircmax...@gmail.com wrote: If that's what it will take I will happily draft one tomorrow morning. But if the RMs are against it, I will respect that as well. Hence the dilemma. For what I understand the RMs are not against what it is proposed but its incompleteness and the fact that it affects the timeline for php 7. The sooner will benefit from a RFC, making this whole discussion a lot clearer. The latter is a requirement to change, even slightly, anything about what we decided for php 7. The RMs role is to ensure we respect what we decided by RFC, hence the oppositions. By the way, I would really like to see other voicing their opinion on the matter, especially those having pushed hard in favour of this timeline.
Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7
Hi, On Fri, Aug 21, 2015 at 4:36 PM, Anthony Ferrara ircmax...@gmail.com wrote: MHO is this is too important of a distinction to simply gloss over. Having it return false (or null) will be a problem, as nobody will perform the error checks. And returning $x where `$x == 0` in a security context could be incredibly bad. As such, I think the security implications here outweigh nearly all of the other concerns about consistency and convention. ^ That! Please don't sweep this under the carpet. Yes, the RFC and release processes are vital, and consistency is desirable, but neither should be an excuse for what could be a horrible mistake here. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7
On 08/21/2015 06:36 AM, Anthony Ferrara wrote: My proposal/stance: Let's make random_* throw an Exception if it cannot connect to a random source. And let's have it throw an TypeError if ZPP fails, or Error if min = max. The first two are consistent with existing exceptions. I don't think anyone would argue those two. It makes sense. The third (Error if minmax) is where the contention lies. I'm suggesting Error as it's consistent with parameter errors in the sense that the type may be correct, but the value isn't (hence it's the same kind of error as a parameter error, just a different sub-classification. MHO is this is too important of a distinction to simply gloss over. Having it return false (or null) will be a problem, as nobody will perform the error checks. And returning $x where `$x == 0` in a security context could be incredibly bad. As such, I think the security implications here outweigh nearly all of the other concerns about consistency and convention. That's my opinion. I'll be happy to make the changes if a RM gives me the green light to do so. An error on this makes sense to me too and it doesn't seem like much of an issue to make this change now. But yes, it is the RM's final call. -Rasmus signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7
On 21.08.2015 at 12:14, Scott Arciszewski wrote: 2. One of the folks in the camp that WANTS an RFC and a drawn out formal decision-making process opens it with a poll. AIUI, that is not how it is supposed to work. Those who want to change existing behavior should make a respective RFC, if consensus couldn't be reached otherwise. 3. Give me voting karma. I suggest you apply for a Git account, see http://php.net/git-php.php. :) -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7
Anatol, On Aug 21, 2015 8:10 PM, Anatol Belski anatol@belski.net wrote: Hi, -Original Message- From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Friday, August 21, 2015 3:37 PM To: Scott Arciszewski sc...@paragonie.com Cc: Pierre Joye pierre@gmail.com; Trevor Suarez ric...@gmail.com ; Niklas Keller m...@kelunik.com; PHP Internals internals@lists.php.net Subject: Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7 On Fri, Aug 21, 2015 at 6:14 AM, Scott Arciszewski sc...@paragonie.com wrote: On Fri, Aug 21, 2015 at 3:52 AM, Pierre Joye pierre@gmail.com wrote: On Fri, Aug 21, 2015 at 9:38 AM, Scott Arciszewski sc...@paragonie.com wrote: On Wed, Aug 19, 2015 at 11:36 AM, Trevor Suarez ric...@gmail.com wrote: Ah, I didn't realize this thread existed. I had just commented on the old one, but the point still stands: PHP 7.0 RC1 was just tagged. Shouldn't this be a relatively high priority to fix/decide so we don't end up with behavior that can't be fixed until PHP 8.0? On Mon, Aug 10, 2015 at 6:54 PM Niklas Keller m...@kelunik.com wrote: Okay, great, we have people on both sides on this discussion. I hope nobody minds if I sit this part out. What specifics need to be discussed? Should somebody set up a poll? (I don't know how to do that.) You can find information on how to setup a poll in step 6 here: https://wiki.php.net/rfc/howto Regards, Niklas I agree that this should be a relatively high priority. I'm not sure what the next steps would be. (Aside: I still have a PR I need to write that I've been holding off on until the fate of PHP 7's CSPRNG feature is determined.) Can we reach some sort of consensus on throw new Exception vs throw new Error? I think the best would be a RFC, not only for the decision itself but also to have a clear view about what will be changed or affected. Cheers, -- Pierre @pierrejoye | http://www.libgd.org Fine, let's do this: 1. Violate the feature freeze for this exceptional decision. 2. One of the folks in the camp that WANTS an RFC and a drawn out formal decision-making process opens it with a poll. 3. Give me voting karma. Let's NOT make the CSPRNG feature fail open. That is an absolutely terrible idea. My proposal/stance: Let's make random_* throw an Exception if it cannot connect to a random source. And let's have it throw an TypeError if ZPP fails, or Error if min = max. The first two are consistent with existing exceptions. The third (Error if minmax) is where the contention lies. I'm suggesting Error as it's consistent with parameter errors in the sense that the type may be correct, but the value isn't (hence it's the same kind of error as a parameter error, just a different sub-classification. MHO is this is too important of a distinction to simply gloss over. Having it return false (or null) will be a problem, as nobody will perform the error checks. And returning $x where `$x == 0` in a security context could be incredibly bad. As such, I think the security implications here outweigh nearly all of the other concerns about consistency and convention. That's my opinion. I'll be happy to make the changes if a RM gives me the green light to do so. The change being proposed was discussed once more in the RM circle and is being seen as inappropriate. The CSPRNG RFC and the implementation was voted. The change being proposed amends the paradigm of the current language behavior. Currently no effort has been done do discuss and work out the paradigm change. By today's terms, there are other functions which could require throwing instead of returning false for security reasons. Security being over BC was and is even in the patch versions, however how it is handled is related to the hard and deeply internal cases like memory corruption, etc. Having a decision that a return value is something security related has impact to the existing behavior. Having different technical requirements to the congeneric cases on the language level brings inconsistency. Producing inconsistent behaviors by one case, without any evaluation and clear course for other cases, without respecting the votes and code freeze is alarming. The current timeline doesn't allow for a proper solution of this topic in 7.0. The RMs recommendation is that everyone expressing a strong support in this thread for the behavior change either for core functions in general or particularly in the security context stands up for a proper solution in 7.1. If no one believes that a proper solution can exist in 7.1, then an inconsistency shouldn't exist in 7.0, except the community wants it to be so which brings it back to an RFC. With respect to everyone who voted on the original implementation of CSPRNG RFC and everyone else regarding the topic throwing
Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7
On Sat, Aug 22, 2015 at 8:43 AM, Anthony Ferrara ircmax...@gmail.com wrote: Anatol, On Aug 21, 2015 8:10 PM, Anatol Belski anatol@belski.net wrote: Hi, -Original Message- From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Friday, August 21, 2015 3:37 PM To: Scott Arciszewski sc...@paragonie.com Cc: Pierre Joye pierre@gmail.com; Trevor Suarez ric...@gmail.com; Niklas Keller m...@kelunik.com; PHP Internals internals@lists.php.net Subject: Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7 On Fri, Aug 21, 2015 at 6:14 AM, Scott Arciszewski sc...@paragonie.com wrote: On Fri, Aug 21, 2015 at 3:52 AM, Pierre Joye pierre@gmail.com wrote: On Fri, Aug 21, 2015 at 9:38 AM, Scott Arciszewski sc...@paragonie.com wrote: On Wed, Aug 19, 2015 at 11:36 AM, Trevor Suarez ric...@gmail.com wrote: Ah, I didn't realize this thread existed. I had just commented on the old one, but the point still stands: PHP 7.0 RC1 was just tagged. Shouldn't this be a relatively high priority to fix/decide so we don't end up with behavior that can't be fixed until PHP 8.0? On Mon, Aug 10, 2015 at 6:54 PM Niklas Keller m...@kelunik.com wrote: Okay, great, we have people on both sides on this discussion. I hope nobody minds if I sit this part out. What specifics need to be discussed? Should somebody set up a poll? (I don't know how to do that.) You can find information on how to setup a poll in step 6 here: https://wiki.php.net/rfc/howto Regards, Niklas I agree that this should be a relatively high priority. I'm not sure what the next steps would be. (Aside: I still have a PR I need to write that I've been holding off on until the fate of PHP 7's CSPRNG feature is determined.) Can we reach some sort of consensus on throw new Exception vs throw new Error? I think the best would be a RFC, not only for the decision itself but also to have a clear view about what will be changed or affected. Cheers, -- Pierre @pierrejoye | http://www.libgd.org Fine, let's do this: 1. Violate the feature freeze for this exceptional decision. 2. One of the folks in the camp that WANTS an RFC and a drawn out formal decision-making process opens it with a poll. 3. Give me voting karma. Let's NOT make the CSPRNG feature fail open. That is an absolutely terrible idea. My proposal/stance: Let's make random_* throw an Exception if it cannot connect to a random source. And let's have it throw an TypeError if ZPP fails, or Error if min = max. The first two are consistent with existing exceptions. The third (Error if minmax) is where the contention lies. I'm suggesting Error as it's consistent with parameter errors in the sense that the type may be correct, but the value isn't (hence it's the same kind of error as a parameter error, just a different sub-classification. MHO is this is too important of a distinction to simply gloss over. Having it return false (or null) will be a problem, as nobody will perform the error checks. And returning $x where `$x == 0` in a security context could be incredibly bad. As such, I think the security implications here outweigh nearly all of the other concerns about consistency and convention. That's my opinion. I'll be happy to make the changes if a RM gives me the green light to do so. The change being proposed was discussed once more in the RM circle and is being seen as inappropriate. The CSPRNG RFC and the implementation was voted. The change being proposed amends the paradigm of the current language behavior. Currently no effort has been done do discuss and work out the paradigm change. By today's terms, there are other functions which could require throwing instead of returning false for security reasons. Security being over BC was and is even in the patch versions, however how it is handled is related to the hard and deeply internal cases like memory corruption, etc. Having a decision that a return value is something security related has impact to the existing behavior. Having different technical requirements to the congeneric cases on the language level brings inconsistency. Producing inconsistent behaviors by one case, without any evaluation and clear course for other cases, without respecting the votes and code freeze is alarming. The current timeline doesn't allow for a proper solution of this topic in 7.0. The RMs recommendation is that everyone expressing a strong support in this thread for the behavior change either for core functions in general or particularly in the security context stands up for a proper solution in 7.1. If no one believes that a proper solution can exist in 7.1, then an inconsistency shouldn't exist in 7.0, except the community wants it to be so which brings it back to an RFC
Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7
Pierre On Aug 21, 2015 22:01, Pierre Joye pierre@gmail.com wrote: On Sat, Aug 22, 2015 at 8:43 AM, Anthony Ferrara ircmax...@gmail.com wrote: Anatol, On Aug 21, 2015 8:10 PM, Anatol Belski anatol@belski.net wrote: Hi, -Original Message- From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Friday, August 21, 2015 3:37 PM To: Scott Arciszewski sc...@paragonie.com Cc: Pierre Joye pierre@gmail.com; Trevor Suarez ric...@gmail.com; Niklas Keller m...@kelunik.com; PHP Internals internals@lists.php.net Subject: Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7 On Fri, Aug 21, 2015 at 6:14 AM, Scott Arciszewski sc...@paragonie.com wrote: On Fri, Aug 21, 2015 at 3:52 AM, Pierre Joye pierre@gmail.com wrote: On Fri, Aug 21, 2015 at 9:38 AM, Scott Arciszewski sc...@paragonie.com wrote: On Wed, Aug 19, 2015 at 11:36 AM, Trevor Suarez ric...@gmail.com wrote: Ah, I didn't realize this thread existed. I had just commented on the old one, but the point still stands: PHP 7.0 RC1 was just tagged. Shouldn't this be a relatively high priority to fix/decide so we don't end up with behavior that can't be fixed until PHP 8.0? On Mon, Aug 10, 2015 at 6:54 PM Niklas Keller m...@kelunik.com wrote: Okay, great, we have people on both sides on this discussion. I hope nobody minds if I sit this part out. What specifics need to be discussed? Should somebody set up a poll? (I don't know how to do that.) You can find information on how to setup a poll in step 6 here: https://wiki.php.net/rfc/howto Regards, Niklas I agree that this should be a relatively high priority. I'm not sure what the next steps would be. (Aside: I still have a PR I need to write that I've been holding off on until the fate of PHP 7's CSPRNG feature is determined.) Can we reach some sort of consensus on throw new Exception vs throw new Error? I think the best would be a RFC, not only for the decision itself but also to have a clear view about what will be changed or affected. Cheers, -- Pierre @pierrejoye | http://www.libgd.org Fine, let's do this: 1. Violate the feature freeze for this exceptional decision. 2. One of the folks in the camp that WANTS an RFC and a drawn out formal decision-making process opens it with a poll. 3. Give me voting karma. Let's NOT make the CSPRNG feature fail open. That is an absolutely terrible idea. My proposal/stance: Let's make random_* throw an Exception if it cannot connect to a random source. And let's have it throw an TypeError if ZPP fails, or Error if min = max. The first two are consistent with existing exceptions. The third (Error if minmax) is where the contention lies. I'm suggesting Error as it's consistent with parameter errors in the sense that the type may be correct, but the value isn't (hence it's the same kind of error as a parameter error, just a different sub-classification. MHO is this is too important of a distinction to simply gloss over. Having it return false (or null) will be a problem, as nobody will perform the error checks. And returning $x where `$x == 0` in a security context could be incredibly bad. As such, I think the security implications here outweigh nearly all of the other concerns about consistency and convention. That's my opinion. I'll be happy to make the changes if a RM gives me the green light to do so. The change being proposed was discussed once more in the RM circle and is being seen as inappropriate. The CSPRNG RFC and the implementation was voted. The change being proposed amends the paradigm of the current language behavior. Currently no effort has been done do discuss and work out the paradigm change. By today's terms, there are other functions which could require throwing instead of returning false for security reasons. Security being over BC was and is even in the patch versions, however how it is handled is related to the hard and deeply internal cases like memory corruption, etc. Having a decision that a return value is something security related has impact to the existing behavior. Having different technical requirements to the congeneric cases on the language level brings inconsistency. Producing inconsistent behaviors by one case, without any evaluation and clear course for other cases, without respecting the votes and code freeze is alarming. The current timeline doesn't allow for a proper solution of this topic in 7.0. The RMs recommendation is that everyone expressing a strong support in this thread for the behavior change either for core functions in general or particularly in the security context stands up for a proper
RE: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7
Hi, -Original Message- From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Friday, August 21, 2015 3:37 PM To: Scott Arciszewski sc...@paragonie.com Cc: Pierre Joye pierre@gmail.com; Trevor Suarez ric...@gmail.com; Niklas Keller m...@kelunik.com; PHP Internals internals@lists.php.net Subject: Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7 On Fri, Aug 21, 2015 at 6:14 AM, Scott Arciszewski sc...@paragonie.com wrote: On Fri, Aug 21, 2015 at 3:52 AM, Pierre Joye pierre@gmail.com wrote: On Fri, Aug 21, 2015 at 9:38 AM, Scott Arciszewski sc...@paragonie.com wrote: On Wed, Aug 19, 2015 at 11:36 AM, Trevor Suarez ric...@gmail.com wrote: Ah, I didn't realize this thread existed. I had just commented on the old one, but the point still stands: PHP 7.0 RC1 was just tagged. Shouldn't this be a relatively high priority to fix/decide so we don't end up with behavior that can't be fixed until PHP 8.0? On Mon, Aug 10, 2015 at 6:54 PM Niklas Keller m...@kelunik.com wrote: Okay, great, we have people on both sides on this discussion. I hope nobody minds if I sit this part out. What specifics need to be discussed? Should somebody set up a poll? (I don't know how to do that.) You can find information on how to setup a poll in step 6 here: https://wiki.php.net/rfc/howto Regards, Niklas I agree that this should be a relatively high priority. I'm not sure what the next steps would be. (Aside: I still have a PR I need to write that I've been holding off on until the fate of PHP 7's CSPRNG feature is determined.) Can we reach some sort of consensus on throw new Exception vs throw new Error? I think the best would be a RFC, not only for the decision itself but also to have a clear view about what will be changed or affected. Cheers, -- Pierre @pierrejoye | http://www.libgd.org Fine, let's do this: 1. Violate the feature freeze for this exceptional decision. 2. One of the folks in the camp that WANTS an RFC and a drawn out formal decision-making process opens it with a poll. 3. Give me voting karma. Let's NOT make the CSPRNG feature fail open. That is an absolutely terrible idea. My proposal/stance: Let's make random_* throw an Exception if it cannot connect to a random source. And let's have it throw an TypeError if ZPP fails, or Error if min = max. The first two are consistent with existing exceptions. The third (Error if minmax) is where the contention lies. I'm suggesting Error as it's consistent with parameter errors in the sense that the type may be correct, but the value isn't (hence it's the same kind of error as a parameter error, just a different sub-classification. MHO is this is too important of a distinction to simply gloss over. Having it return false (or null) will be a problem, as nobody will perform the error checks. And returning $x where `$x == 0` in a security context could be incredibly bad. As such, I think the security implications here outweigh nearly all of the other concerns about consistency and convention. That's my opinion. I'll be happy to make the changes if a RM gives me the green light to do so. The change being proposed was discussed once more in the RM circle and is being seen as inappropriate. The CSPRNG RFC and the implementation was voted. The change being proposed amends the paradigm of the current language behavior. Currently no effort has been done do discuss and work out the paradigm change. By today's terms, there are other functions which could require throwing instead of returning false for security reasons. Security being over BC was and is even in the patch versions, however how it is handled is related to the hard and deeply internal cases like memory corruption, etc. Having a decision that a return value is something security related has impact to the existing behavior. Having different technical requirements to the congeneric cases on the language level brings inconsistency. Producing inconsistent behaviors by one case, without any evaluation and clear course for other cases, without respecting the votes and code freeze is alarming. The current timeline doesn't allow for a proper solution of this topic in 7.0. The RMs recommendation is that everyone expressing a strong support in this thread for the behavior change either for core functions in general or particularly in the security context stands up for a proper solution in 7.1. If no one believes that a proper solution can exist in 7.1, then an inconsistency shouldn't exist in 7.0, except the community wants it to be so which brings it back to an RFC. With respect to everyone who voted on the original implementation of CSPRNG RFC and everyone else regarding the topic throwing in the core functions it should be accepted in the usual ways that are foreseen. Best regards Anatol -- PHP Internals - PHP
Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7
On Aug 22, 2015 7:39 AM, Christoph Becker cmbecke...@gmx.de wrote: On 21.08.2015 at 12:14, Scott Arciszewski wrote: 2. One of the folks in the camp that WANTS an RFC and a drawn out formal decision-making process opens it with a poll. AIUI, that is not how it is supposed to work. Those who want to change existing behavior should make a respective RFC, if consensus couldn't be reached otherwise. Do you mean a change like this can be applied without rfc? If yes, I disagree. 3. Give me voting karma. I suggest you apply for a Git account, see http://php.net/git-php.php. :) Ack :) -- Christoph M. Becker
Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7
On Fri, Aug 21, 2015 at 9:38 AM, Scott Arciszewski sc...@paragonie.com wrote: On Wed, Aug 19, 2015 at 11:36 AM, Trevor Suarez ric...@gmail.com wrote: Ah, I didn't realize this thread existed. I had just commented on the old one, but the point still stands: PHP 7.0 RC1 was just tagged. Shouldn't this be a relatively high priority to fix/decide so we don't end up with behavior that can't be fixed until PHP 8.0? On Mon, Aug 10, 2015 at 6:54 PM Niklas Keller m...@kelunik.com wrote: Okay, great, we have people on both sides on this discussion. I hope nobody minds if I sit this part out. What specifics need to be discussed? Should somebody set up a poll? (I don't know how to do that.) You can find information on how to setup a poll in step 6 here: https://wiki.php.net/rfc/howto Regards, Niklas I agree that this should be a relatively high priority. I'm not sure what the next steps would be. (Aside: I still have a PR I need to write that I've been holding off on until the fate of PHP 7's CSPRNG feature is determined.) Can we reach some sort of consensus on throw new Exception vs throw new Error? I think the best would be a RFC, not only for the decision itself but also to have a clear view about what will be changed or affected. 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] Recap - Core functions throwing exceptions in PHP7
On Fri, Aug 21, 2015 at 3:52 AM, Pierre Joye pierre@gmail.com wrote: On Fri, Aug 21, 2015 at 9:38 AM, Scott Arciszewski sc...@paragonie.com wrote: On Wed, Aug 19, 2015 at 11:36 AM, Trevor Suarez ric...@gmail.com wrote: Ah, I didn't realize this thread existed. I had just commented on the old one, but the point still stands: PHP 7.0 RC1 was just tagged. Shouldn't this be a relatively high priority to fix/decide so we don't end up with behavior that can't be fixed until PHP 8.0? On Mon, Aug 10, 2015 at 6:54 PM Niklas Keller m...@kelunik.com wrote: Okay, great, we have people on both sides on this discussion. I hope nobody minds if I sit this part out. What specifics need to be discussed? Should somebody set up a poll? (I don't know how to do that.) You can find information on how to setup a poll in step 6 here: https://wiki.php.net/rfc/howto Regards, Niklas I agree that this should be a relatively high priority. I'm not sure what the next steps would be. (Aside: I still have a PR I need to write that I've been holding off on until the fate of PHP 7's CSPRNG feature is determined.) Can we reach some sort of consensus on throw new Exception vs throw new Error? I think the best would be a RFC, not only for the decision itself but also to have a clear view about what will be changed or affected. Cheers, -- Pierre @pierrejoye | http://www.libgd.org Fine, let's do this: 1. Violate the feature freeze for this exceptional decision. 2. One of the folks in the camp that WANTS an RFC and a drawn out formal decision-making process opens it with a poll. 3. Give me voting karma. Let's NOT make the CSPRNG feature fail open. That is an absolutely terrible idea. Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises https://paragonie.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7
On Wed, Aug 19, 2015 at 11:36 AM, Trevor Suarez ric...@gmail.com wrote: Ah, I didn't realize this thread existed. I had just commented on the old one, but the point still stands: PHP 7.0 RC1 was just tagged. Shouldn't this be a relatively high priority to fix/decide so we don't end up with behavior that can't be fixed until PHP 8.0? On Mon, Aug 10, 2015 at 6:54 PM Niklas Keller m...@kelunik.com wrote: Okay, great, we have people on both sides on this discussion. I hope nobody minds if I sit this part out. What specifics need to be discussed? Should somebody set up a poll? (I don't know how to do that.) You can find information on how to setup a poll in step 6 here: https://wiki.php.net/rfc/howto Regards, Niklas I agree that this should be a relatively high priority. I'm not sure what the next steps would be. (Aside: I still have a PR I need to write that I've been holding off on until the fate of PHP 7's CSPRNG feature is determined.) Can we reach some sort of consensus on throw new Exception vs throw new Error? Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises https://paragonie.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7
Ah, I didn't realize this thread existed. I had just commented on the old one, but the point still stands: PHP 7.0 RC1 was just tagged. Shouldn't this be a relatively high priority to fix/decide so we don't end up with behavior that can't be fixed until PHP 8.0? On Mon, Aug 10, 2015 at 6:54 PM Niklas Keller m...@kelunik.com wrote: Okay, great, we have people on both sides on this discussion. I hope nobody minds if I sit this part out. What specifics need to be discussed? Should somebody set up a poll? (I don't know how to do that.) You can find information on how to setup a poll in step 6 here: https://wiki.php.net/rfc/howto Regards, Niklas
Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7
On Thu, Aug 6, 2015 at 4:52 AM, Niklas Keller m...@kelunik.com wrote: Scott, could you setup a RFC with a vote, so we can decide? Nikita proposed those two options: 1) Error is to be used in cases where an error is attributable to programmer mistake. 2) Error signifies a failure condition that the programmer is discouraged (and unlikely to want) to handle. It should only be dealt with at the top level. I'm in favor of 2), I would phrase it like: Error should be used if a repetitive call with the same input parameters would _permanently_ result in a failure, otherwise Exception. Regards, Niklas On Fri, Aug 7, 2015 at 1:38 AM, Aaron Piotrowski aa...@icicle.io wrote: On Aug 6, 2015, at 3:52 AM, Niklas Keller m...@kelunik.com wrote: Scott, could you setup a RFC with a vote, so we can decide? Nikita proposed those two options: 1) Error is to be used in cases where an error is attributable to programmer mistake. 2) Error signifies a failure condition that the programmer is discouraged (and unlikely to want) to handle. It should only be dealt with at the top level. I'm in favor of 2), I would phrase it like: Error should be used if a repetitive call with the same input parameters would _permanently_ result in a failure, otherwise Exception. Regards, Niklas I’m in favor of 1), as this was my original intention of the Error branch of exceptions. Errors should be attributable to a programming mistake that should be corrected. Exception should be thrown for unexpected conditions that are not due to programmer error, but instead things like IO or permission errors. I think this is how exceptions thrown from core functions (and all functions or methods in extensions) should be organized. Based on this interpretation, random_int() should throw an Error if $min $max and random_bytes() should throw an Error if $length = 0. random_bytes() and random_int() should throw an Exception if random data cannot be generated. Another quote from Nikita’s message to the prior thread: Another interesting aspect are the zpp calls. Currently these will throw a warning and return NULL in weak mode and throw a TypeError in strict mode. I wonder whether we should be using zpp_throw for new functions, so a TypeError is also thrown in weak mode. Continuing to use the old warning+NULL behavior was a BC concern, which we don't have for new functions. The reason why I think this is worth considering, is that if all other error conditions of a function already throw, then ordinary zpp will still add one case where a different type is returned on error. This makes random_int from a function returning int, to a function returning int|null. I would also be in favor of throwing TypeError from zpp calls in new functions (and quite frankly, from zpp calls in all functions, including old functions). Regards, Aaron Piotrowski Okay, great, we have people on both sides on this discussion. I hope nobody minds if I sit this part out. What specifics need to be discussed? Should somebody set up a poll? (I don't know how to do that.) Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises https://paragonie.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7
Okay, great, we have people on both sides on this discussion. I hope nobody minds if I sit this part out. What specifics need to be discussed? Should somebody set up a poll? (I don't know how to do that.) You can find information on how to setup a poll in step 6 here: https://wiki.php.net/rfc/howto Regards, Niklas
Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7
On Thu, 6 Aug 2015 00:55 Scott Arciszewski sc...@paragonie.com wrote: All, I'd like to move the conversation towards a decision regarding PRs 1397 and 1398. These decisions are blocking random_compat as well as a security enhancement to random_bytes (merge conflicts are *the worst*). Here's a quick recap Arguments: 1. Consistency is more important than security. random_* should be consistent with the rest of PHP (sans intdiv()). They should return false and emit an E_WARNING or E_ERROR warning (the latter is if we want it to fail closed). It's the responsibility of the developer to know this can happen and explicitly check for it. Don't throw anything. 2. Security is more important than consistency. Placing more responsibility on the developer increases the likelihood of an implementation error. We should aim for compatible usability with rand() and mt_rand() for random_int(), which never return false. For random_int() and random_bytes(), should PHP be unable to generate a random value (no random device available, file descriptor exhaustion, etc.) an exception should be thrown. If the developer wants to handle it gracefully, they can place it in try/catch blocks (which raising errors make messy). Otherwise, the default state is to fail closed (i.e. terminate script execution). Open Questions: 1. Under what conditions should an Exception be thrown, and which should throw an Error instead? Did I miss any? I'm in favor of throwing *something*. As for the particulars of what should be an Exception and what should be an Error, I don't have a horse in this race. Exceptions already existed and Errors were already accepted in the Throwable RFC, so I don't believe this warrants another RFC and putting this decision off until 7.1. Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises https://paragonie.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php We also -need- a consensus in place because we have more security sensitive features targeting 7.1 and we don't want to have this argument again. Throwing exception's may not be consistent right now, but it certainly should be in the future. The transition to a new consistency has to start somewhere.
Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7
On Aug 6, 2015, at 3:52 AM, Niklas Keller m...@kelunik.com wrote: Scott, could you setup a RFC with a vote, so we can decide? Nikita proposed those two options: 1) Error is to be used in cases where an error is attributable to programmer mistake. 2) Error signifies a failure condition that the programmer is discouraged (and unlikely to want) to handle. It should only be dealt with at the top level. I'm in favor of 2), I would phrase it like: Error should be used if a repetitive call with the same input parameters would _permanently_ result in a failure, otherwise Exception. Regards, Niklas I’m in favor of 1), as this was my original intention of the Error branch of exceptions. Errors should be attributable to a programming mistake that should be corrected. Exception should be thrown for unexpected conditions that are not due to programmer error, but instead things like IO or permission errors. I think this is how exceptions thrown from core functions (and all functions or methods in extensions) should be organized. Based on this interpretation, random_int() should throw an Error if $min $max and random_bytes() should throw an Error if $length = 0. random_bytes() and random_int() should throw an Exception if random data cannot be generated. Another quote from Nikita’s message to the prior thread: Another interesting aspect are the zpp calls. Currently these will throw a warning and return NULL in weak mode and throw a TypeError in strict mode. I wonder whether we should be using zpp_throw for new functions, so a TypeError is also thrown in weak mode. Continuing to use the old warning+NULL behavior was a BC concern, which we don't have for new functions. The reason why I think this is worth considering, is that if all other error conditions of a function already throw, then ordinary zpp will still add one case where a different type is returned on error. This makes random_int from a function returning int, to a function returning int|null. I would also be in favor of throwing TypeError from zpp calls in new functions (and quite frankly, from zpp calls in all functions, including old functions). Regards, Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7
Scott, could you setup a RFC with a vote, so we can decide? Nikita proposed those two options: 1) Error is to be used in cases where an error is attributable to programmer mistake. 2) Error signifies a failure condition that the programmer is discouraged (and unlikely to want) to handle. It should only be dealt with at the top level. I'm in favor of 2), I would phrase it like: Error should be used if a repetitive call with the same input parameters would _permanently_ result in a failure, otherwise Exception. Regards, Niklas
[PHP-DEV] Recap - Core functions throwing exceptions in PHP7
All, I'd like to move the conversation towards a decision regarding PRs 1397 and 1398. These decisions are blocking random_compat as well as a security enhancement to random_bytes (merge conflicts are *the worst*). Here's a quick recap Arguments: 1. Consistency is more important than security. random_* should be consistent with the rest of PHP (sans intdiv()). They should return false and emit an E_WARNING or E_ERROR warning (the latter is if we want it to fail closed). It's the responsibility of the developer to know this can happen and explicitly check for it. Don't throw anything. 2. Security is more important than consistency. Placing more responsibility on the developer increases the likelihood of an implementation error. We should aim for compatible usability with rand() and mt_rand() for random_int(), which never return false. For random_int() and random_bytes(), should PHP be unable to generate a random value (no random device available, file descriptor exhaustion, etc.) an exception should be thrown. If the developer wants to handle it gracefully, they can place it in try/catch blocks (which raising errors make messy). Otherwise, the default state is to fail closed (i.e. terminate script execution). Open Questions: 1. Under what conditions should an Exception be thrown, and which should throw an Error instead? Did I miss any? I'm in favor of throwing *something*. As for the particulars of what should be an Exception and what should be an Error, I don't have a horse in this race. Exceptions already existed and Errors were already accepted in the Throwable RFC, so I don't believe this warrants another RFC and putting this decision off until 7.1. Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises https://paragonie.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
