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 Updated by: requinix@php.net 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: 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 Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [2021-09-05 14:39:51] php-bugs at allenjb dot me dot uk You can already silence this warning in your own code using a custom error handler. See https://www.php.net/set_error_handler You should however keep in mind that warnings tend to get escalated to errors over time (this was a notice since at least 5.4) The null coalescing operator also provides an alternative "fix" that you may find more readable - like isset() it silences warnings about undefined indexes (and properties or variables): https://www.php.net/manual/en/migration70.new-features.php#migration70.new-features.null-coalesce-op In the case you gave, you would write: if ($array['key'] ?? false) ------------------------------------------------------------------------ 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