[PHP-DEV] Re: [RFC] Reclassifying engine warnings
On 28/08/2019 10:33, Nikita Popov wrote: https://wiki.php.net/rfc/engine_warnings I am 100% behind the exception proposals, however I did want to discuss the warnings. I am personally of the belief that there should be a distinction made between notices / warnings issued by the engine, and those issued by extensions, including standard. I am one of a large number of developers that enforces a "No notice or warning" requirement on their codebases. To this end I use a global error handler that converts ANY notice or error to an \Error exception (within our specific code, so excluding anything in /vendor and the likes). This does however, effect function calls as well, and it's less ideal to have function calls throwing Error, something derived from Exception would make more sense. The issue is which is which. If this does pass, I was wondering if there would be any appetite for re-using the E_CORE_XXX error error codes specifically to refer to ALL engine warnings, not just those at startup. Alternatively, the passing of a bitflag to indicate they came from the engine while still preserving the original bit, although that may be more of a BC break due to requiring bitwise mask comparison in existing handlers. Either way, this this would allow easily differentiating engine warnings that will become more prominent in this RFC, with those contained in PHP_FUNCTION scope. -- Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Reclassifying engine warnings
Den 2019-09-10 kl. 15:31, skrev Nikita Popov: On Wed, Aug 28, 2019 at 11:33 AM Nikita Popov wrote: Hi internals, I think it's time to take a look at our existing warnings & notices in the engine, and think about whether their current classification is still appropriate. Error conditions like "undefined variable" only generating a notice is really quite mind-boggling. I've prepared an RFC with some suggested classifications, though there's room for bikeshedding here... https://wiki.php.net/rfc/engine_warnings Regards, Nikita Heads up: This RFC may go to vote tomorrow. Nikita Hi, I recall an issue brought up about treatment of logfiles in production environment where PHP warning messages show up. Now, this RFC reclassifies some notices to warnings and some warnings to errors. Now suppose one have as a strategy to correct warnings & errors in logfiles, given that this RFC will lead to new items showing up in logfiles. Is it then worth mentioning in the RFC how this will affect handling to correct warnings & errors in logfiles? E.g. face the changes and fix it or write some clever error handler to manage it or just try to suppress the new items. Anyway, I'm in favour of this RFC since it gives a more consistent classification of notices, warnings & errors. r//Björn L -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] Reclassifying engine warnings
On Wed, Aug 28, 2019 at 11:33 AM Nikita Popov wrote: > Hi internals, > > I think it's time to take a look at our existing warnings & notices in the > engine, and think about whether their current classification is still > appropriate. Error conditions like "undefined variable" only generating a > notice is really quite mind-boggling. > > I've prepared an RFC with some suggested classifications, though there's > room for bikeshedding here... > > https://wiki.php.net/rfc/engine_warnings > > Regards, > Nikita > Heads up: This RFC may go to vote tomorrow. Nikita
Re: [PHP-DEV] Re: [RFC] Reclassifying engine warnings
I'm sorry, but if you seriously believe doing something that generates a notice (or warning, or error, ...) is not a bug - you're delusional. That is the very definition of a bug and notices/warnings/errors etc. are the mechanism the language uses to report these bugs to the developer. If doing X has been generating a notice for 20 years, then doing X is wrong and a bug, period. Why would there even be a notice if the language itself doesn't consider what you're doing to be buggy? What is the purpose of notices then? I really don't understand how anyone could contest this. On 29.08.19 07:40, Zeev Suraski wrote: > > It's really awkward that anybody would be under the illusion that the way > the language always behaved, consistently and well-documented pretty much > from the its inception, is somehow a bug that everybody agrees on that's > just waiting for someone to come over and fix it.
Re: [PHP-DEV] Re: [RFC] Reclassifying engine warnings
On Wed, Aug 28, 2019 at 10:26 PM Nikita Popov wrote: > On Wed, Aug 28, 2019 at 11:33 AM Nikita Popov > wrote: > > Reading this discussion has been disappointing and somewhat disillusioning. > I can understand and appreciate the concern for legacy code. But seeing the > use of undefined variables espoused as a legitimate programming style, that > just makes me sad. > Nikita, It's really awkward that anybody would be under the illusion that the way the language always behaved, consistently and well-documented pretty much from the its inception, is somehow a bug that everybody agrees on that's just waiting for someone to come over and fix it. Do you really think that if there was widespread consensus that this wasn't a legitimate programming style, we'd have to wait for 20 years for folks to propose to change/remove it? This isn't short tags - this is fundamental language behavior, that indeed isn't even documented anywhere as a 'bad thing you must avoid'. There are commonly used code templates that rely on it, and do it in a way many would find perfectly reasonable. Many do, and always did consider it as a legitimate programming style. Many others do not - which is why we added capabilities ages ago (from the get go, for all practical purposes) that allow users to employ a much stricter programming style by enabling notices. We never, ever, at any point, considered this behavior to be 'legacy'. It's a language feature, that you can choose whether you want to use or not (and perhaps we can get better at that). The fact that PHP isn't supposed to be a strict language is repeatedly confused with exclusive concern for 'legacy code' as of late. Yes, the complete disregard for backwards compatibility that appears to be the most widely accepted POV on internals is disconcerting - but much more importantly - just because one doesn't like a certain fundamental part of the language, doesn't make the use of it 'legacy'. If anything, it perhaps means that said person who chose the language made the wrong choice (there are plenty of other choices to choose from), and they're now campaigning to change it to fit the image of what they think it *should be* that they have in mind. With that said - I think it does make sense to try and come up with ways to cater to those who prefer a stricter language, and in this particular case - something that's a bit more aggressive than notices. But if there's something sad about this, it's the insistence to always frame the discussion as a zero sum game - instead of trying to find solutions that cater to a wider audiences. It's time to accept that the composition of PHP users is a lot wider than what's represented on internals, and it's certainly not everyone's opinion that the current language is in dire need of being rescued. PHP can be improved for those who find it lacking, without harming those who are in fact happy with the way it currently is. We should start looking for such solutions, instead of each just trying to 'win for their own camp', putting things to a vote hoping to subjugate the other. Zeev
[PHP-DEV] Re: [RFC] Reclassifying engine warnings
On Wed, Aug 28, 2019 at 11:33 AM Nikita Popov wrote: > Hi internals, > > I think it's time to take a look at our existing warnings & notices in the > engine, and think about whether their current classification is still > appropriate. Error conditions like "undefined variable" only generating a > notice is really quite mind-boggling. > > I've prepared an RFC with some suggested classifications, though there's > room for bikeshedding here... > > https://wiki.php.net/rfc/engine_warnings > > Regards, > Nikita > It seems quite clear to me that the question of the "undefined variable" error is contentious. As such, I have decided to split it off into a separate section in the proposal, that will be voted separately from the rest. I will offer the choice of throwing an Error exception (as originally proposed), throwing a warning or keeping the existing notice. Reading this discussion has been disappointing and somewhat disillusioning. I can understand and appreciate the concern for legacy code. But seeing the use of undefined variables espoused as a legitimate programming style, that just makes me sad. Regards, Nikita
[PHP-DEV] Re: [RFC] Reclassifying engine warnings
On 28/08/2019 10:33, Nikita Popov wrote: Hi internals, https://wiki.php.net/rfc/engine_warnings This is an absolutely outstanding move and I certainly hope it gets passed unanimously. PHP as a whole has traditionally been a language that is insanely forgiving of errors, in many cases allowing code execution to continue as if they never even happened, even in utterly egregious cases, and that is certainly something that has played a part in PHP's reputational difficulties. I am extremely happy to see this and other changes underway to reverse these historic failings. It can only be a good thing for the PHP ecosystem as a whole to have the engine and core extensions enforce better protections against bad or potentially buggy code. It won't be an instant transition, and there will be a lot of hold-outs on 7.4 who just don't want to deal with it, but as people do eventually migrate to 8.0, this error-throwing behaviour will force programmers to improve their code rather than just consign the problem to the /dev/null error log. These changes are, no doubt, going to be a painful wake up call for our friends in the community who are, shall we say, not as focused on the quality of their code as we (and their customers) would perhaps like them to be. For everyone else, it's one more tool to help make us aware of problems, and prevent those problems from propagating along the stack and effecting other things. Bring it on. -- Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
