# Recap - Core functions throwing exceptions in PHP7 - Thread: https://externals.io/message/87657 - Original archive: https://news-web.php.net/php.internals/87657 - Started by Scott Arciszewski on 2015-08-05T23:55:14+00:00 - Messages: 27 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/87657.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #87657 — Scott Arciszewski — 2015-08-05T23:55:14+00:00 URL: https://externals.io/message/87657#87657 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 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 -- 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. --- ## #87665 — Niklas Keller — 2015-08-06T08:52:05+00:00 URL: https://externals.io/message/87657#87665 · In reply to: #87663 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 --- ## #87675 — Aaron Piotrowski — 2015-08-07T05:38:08+00:00 URL: https://externals.io/message/87657#87675 · In reply to: #87665 > > > Scott, could you setup a RFC with a vote, so we can decide? > > Nikita proposed those two options: > > > […] > > > > […] > > > 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 --- ## #87699 — Scott Arciszewski — 2015-08-10T14:41:27+00:00 URL: https://externals.io/message/87657#87699 > Scott, could you setup a RFC with a vote, so we can decide? > > Nikita proposed those two options: > > > […] > > > 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: > > > […] > > 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 > 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 --- ## #87807 — Trevor Suarez — 2015-08-19T15:36:49+00:00 URL: https://externals.io/message/87657#87807 · In reply to: #87703 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? > > […] > > > You can find information on how to setup a poll in step 6 here: > https://wiki.php.net/rfc/howto > > Regards, Niklas --- ## #87826 — Scott Arciszewski — 2015-08-21T02:38:10+00:00 URL: https://externals.io/message/87657#87826 · In reply to: #87807 > 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? > > > > […] 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 > > […] > > 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 --- ## #87834 — Scott Arciszewski — 2015-08-21T10:14:12+00:00 URL: https://externals.io/message/87657#87834 · In reply to: #87827 > > > […] > > 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 > > […] > > 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 min>max) 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. Thanks Anthony --- ## #87845 — Andrey Andreev — 2015-08-21T21:26:49+00:00 URL: https://externals.io/message/87657#87845 · In reply to: #87838 Hi, > > 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. --- ## #87848 — Rasmus Lerdorf — 2015-08-21T22:00:27+00:00 URL: https://externals.io/message/87657#87848 · In reply to: #87838 > 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 min>max) 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 --- ## #87849 — Anatol Belski — 2015-08-22T00:10:42+00:00 URL: https://externals.io/message/87657#87849 · In reply to: #87838 Hi, > -----Original Message----- > From: Anthony Ferrara [mailto:ircmaxell@gmail.com] > Sent: Friday, August 21, 2015 3:37 PM > To: Scott Arciszewski > Cc: Pierre Joye ; Trevor Suarez ; > Niklas Keller ; PHP Internals > Subject: Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7 > > On Fri, Aug 21, 2015 at 6:14 AM, Scott Arciszewski > wrote: > > […] > wrote: > > […] > wrote: > > […] > new Error? > > […] > > 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 min>max) 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 --- ## #87850 — Christoph Becker — 2015-08-22T00:40:01+00:00 URL: https://externals.io/message/87657#87850 · In reply to: #87834 > 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 . :) -- Christoph M. Becker --- ## #87851 — Pierre Joye — 2015-08-22T01:02:29+00:00 URL: https://externals.io/message/87657#87851 · In reply to: #87850 > > > > > […] > > 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 suggest you apply for a Git account, see . :) Ack :) > -- > Christoph M. Becker --- ## #87853 — Anthony Ferrara — 2015-08-22T01:43:04+00:00 URL: https://externals.io/message/87657#87853 · In reply to: #87849 Anatol, > > Hi, > > > […] >; > > […] PHP7 > > […] wrote: > > […] scott@paragonie.com> > > […] wrote: > > […] min >= max. > > […] suggesting Error as > > […] correct, > > […] error, just a > > […] perform the error > > […] incredibly > > […] all of the > > […] the green > > […] > 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. Thank you for sharing your thoughts and being transparent. There is one tiny thing I would point out though (which likely makes no difference). When the random rfc was voted on, engine exceptions was not accepted. It was a conscious decision by the contributors to not have the function throw because nothing throws in core. That changed with the later rfc. Hence why this was reopened. The discussion has been biked shedded to death. From before beta1. And unfortunately it looks like it has just been bike shedded out of contention for 7.0, which is sad on many levels. But this is where we are today. While I think it is less than optimal, so be it. Thank you for the time and for everything you do/are doing for the project. Anthony --- ## #87854 — Pierre Joye — 2015-08-22T02:01:02+00:00 URL: https://externals.io/message/87657#87854 · In reply to: #87853 > Anatol, > > > > […] > > Thank you for sharing your thoughts and being transparent. > > There is one tiny thing I would point out though (which likely makes no > difference). When the random rfc was voted on, engine exceptions was not > accepted. It was a conscious decision by the contributors to not have the > function throw because nothing throws in core. That changed with the later > rfc. Hence why this was reopened. > > The discussion has been biked shedded to death. From before beta1. And > unfortunately it looks like it has just been bike shedded out of contention > for 7.0, which is sad on many levels. > > But this is where we are today. While I think it is less than optimal, so be > it. I do think as well it is better to solve this question for 7.0. It is a kind of big thing even the code changes may be small. Dealing with that for 7.1 and 7.0 will most likely be painful. However we have chosen to have a short timeline to release 7.0. We knew the risks of having such issues to solve. I personally would not mind too much to have a RFC for this case as long as it includes an option to slightly delay 7.0 if necessary. Cheers, -- Pierre @pierrejoye | http://www.libgd.org --- ## #87855 — Anthony Ferrara — 2015-08-22T02:16:53+00:00 URL: https://externals.io/message/87657#87855 · In reply to: #87854 Pierre > > On Sat, Aug 22, 2015 at 8:43 AM, Anthony Ferrara wrote: > > […] internals@lists.php.net> > > […] scott@paragonie.com> > > […] > > > […] on > > […] discussion. I > > […] sure > > […] CSPRNG > > […] throw > > […] but > > […] random > > […] if > > […] be > > […] be > > […] all > > […] is > > […] proposed > > […] effort > > […] throwing > > […] BC was > > […] related to > > […] a > > […] to the > > […] congeneric > > […] inconsistent > > […] other > > […] in > > […] support in > > […] general or > > […] in 7.1. > > […] be so > > […] the > > […] topic > > […] ways > > […] the > > […] later > > […] contention > > […] so be > > […] > > I do think as well it is better to solve this question for 7.0. It is > a kind of big thing even the code changes may be small. Dealing with > that for 7.1 and 7.0 will most likely be painful. > > However we have chosen to have a short timeline to release 7.0. We > knew the risks of having such issues to solve. I personally would not > mind too much to have a RFC for this case as long as it includes an > option to slightly delay 7.0 if necessary. 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. Anthony --- ## #87856 — Scott Arciszewski — 2015-08-22T02:29:19+00:00 URL: https://externals.io/message/87657#87856 · In reply to: #87855 > > Pierre > > > > […] > > 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. > > Anthony For the sake of compatibility, I'll make the necessary changes to random_compat tonight. Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises 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 --- ## #87858 — Anthony Ferrara — 2015-08-22T02:44:10+00:00 URL: https://externals.io/message/87657#87858 · In reply to: #87857 Pierre > > On Sat, Aug 22, 2015 at 9:16 AM, Anthony Ferrara wrote: > > > […] But > > […] 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 --- ## #87859 — Pierre Joye — 2015-08-22T02:46:42+00:00 URL: https://externals.io/message/87657#87859 · In reply to: #87857 > > On Sat, Aug 22, 2015 at 9:16 AM, Anthony Ferrara wrote: > > > […] But > > […] 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. --- ## #87861 — Nikita Popov — 2015-08-22T10:17:15+00:00 URL: https://externals.io/message/87657#87861 · In reply to: #87849 On Sat, Aug 22, 2015 at 2:10 AM, Anatol Belski wrote: > Hi, > > > […] > wrote: > > […] > scott@paragonie.com> > > […] > wrote: > > […] > min >= max. > > […] > suggesting Error as > > […] > correct, > > […] > error, just a > > […] > perform the error > > […] > incredibly > > […] > of the > > […] > the green > > […] > 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 --- ## #87862 — Christoph Becker — 2015-08-22T11:09:46+00:00 URL: https://externals.io/message/87657#87862 · In reply to: #87851 > > > […] > > 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 --- Next page: https://externals.io/message/87657.md?page=2