Req #81417 [Wfx]: Option to determine if reading an undefined array key should throw a warning

Edit report at https://bugs.php.net/bug.php?id=81417&edit=1 ID: 81417 User updated by: nicolas at gestixi dot com Reported by: nicolas at gestixi dot com Summary: Option to determine if reading an undefined array key should throw a warning Status: Wont fix Type: Feature/Change Request Package: *Configuration Issues PHP Version: 8.0.10 Block user comment: N Private report: N New Comment: Thank you a lot for coming back to this. #1. For me it is only the "Undefined array key" warning which is problematic. The best for me would be to simply return undefined (like in javascript) without warning or notice. #2. Nope, only this one. #3. For me, no matter if it is an exception, a warning or a notice, it should have a setting to accept this behavior. #4. For this warning, I think that PHP should simply remove nuisance warnings entirely and thus allow developers to ignore the sorts of problems they were intended to point out. #5. Yes, and it is not appropriate for us as we would have to use it at hundreds of places. We just want to be able to check if a property exists by accessing it, like this: if ($array['key']). And this has been used everywhere in our code base. Here https://wiki.php.net/rfc/engine_warnings, we can see the 'Undefined array index' error was controversial. For us having them as notice is also problematic as we have to completely disable notices. Thanks in advance for considering this request. I should have woken up earlier. If I can be of any help with this, please don't hesitate to ask. Previous Comments: ------------------------------------------------------------------------ [2022-02-09 09:02:44] requinix@php.net Maybe I should have tried asking for more information before closing it. I'll start with a few easy questions. #1. I have here a sample of 15 different warnings and notices: https://3v4l.org/l8pSY Which of those should be suppressable by new php.ini settings? Or did I misunderstand, and the request is only about one very specific warning that should be handled with one very specific setting, with a steadfast opposition to the unintentional emergence of a "well we did it for X so why not do it for Y"-type precedent? #2. Hypothetically, what about all the other sorts of warning and notices that are currently being raised throughout PHP? Are any of them also causing you undue problems as you attempt to update a 10 year old application that was developed in the days of PHP 5.3? https://github.com/php/php-src/search?l=PHP&q=warning #3. Given PHP's trend of turning suitable warnings into exceptions, should the settings also extend to suppressing the throwing of those exceptions? Or does it make more sense to spend time adding try/catch blocks to userland code (or, perhaps more sensibly, to disregard the possibility of exceptions entirely) than to wrap questionable array accesses in calls to empty()? #4. Considering that you feel it is appropriate to ignore at least one type of warning across your application, do you think that PHP should simply remove nuisance warnings entirely and thus allow developers to ignore the sorts of problems they were intended to point out? Or are you concerned that there may be some number of unknown bugs that could be swept under the rug by a unilateral move to remove warnings for the sake of convenience? #5. Have you heard of the @ operator? Unlike everything else in this reply, I really do mean to ask this without being facetious, as I believe this is likely the most appropriate solution to the problem. Also, my apologies on behalf of all the PHP developers here for making the sudden decision that an attempt to access an undefined array key should now result in a warning, and for doing so without observing the RFC process by holding a public vote-- oh, wait, no, my bad, actually there was one about this. https://wiki.php.net/rfc/engine_warnings Unfortunately the discussion for that RFC was conducted privately between individuals with exclusive access to a secret mailing list that-- oh, nope, I'm sorry, that's not right either. https://externals.io/message/106713 ------------------------------------------------------------------------ [2022-02-09 07:00:45] nicolas at gestixi dot com Indeed it would be great to know why it is such a very dangerous door... We still have not started to upgrade our codebase. We have 138627 lines of code to review just because of this "useless" warning. I will have to find a way to automate most of it, or spend weeks doing it… ------------------------------------------------------------------------ [2022-02-08 17:20:29] k dot andris at gmail dot com "is opening a very big and very dangerous door that really ought to remain closed"... funny. It's a door that's been wide open for many years. It would be helpful requinix, if you'd point us to an RFC or somethine where making this backward incompatible change has been decide instead of lecturing loyal developers. Also keeping them from running away to other languages as I did. Thanks. ------------------------------------------------------------------------ [2021-09-06 01:50:52] requinix@php.net As a rule of thumb, adding another php.ini option is not the right answer. What's more, adding one that tells PHP to ignore certain types of warnings/errors is opening a very big and very dangerous door that really ought to remain closed. If your codebase is 10 years old then you'll have to accept that you cannot simply upgrade PHP versions (especially majors) and expect everything to work as it did back in 2011. PHP 7.4 is the last of the 7.x series and will remain in active support for an extended period - use that time to upgrade your codebase to be compatible with 8.x. ------------------------------------------------------------------------ [2021-09-05 18:41:06] nicolas at gestixi dot com I tried with a custom error handler. Something like: if (strpos($errstr, 'Undefined index:') !== false OR strpos($errstr, 'Undefined offset:') !== false) return true; else return false; But it exhausts the memory before the end of the request. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=81417 -- Edit this bug report at https://bugs.php.net/bug.php?id=81417&edit=1