wish: config option to make undefined array key a notice again

[RichardNeill]

Description

In PHP 7, underfined array keys created E_NOTICE. This is now E_WARNING.
Can we please have a configuration option to put that back to E_NOTICE?

Rightly or wrongly, there are a lot of people, myself included, who have thousands of lines of code with things such as:
if ($_GET['xxx']) #where xxx may or may not exist.
or
if ($_GET['xxx'] == 'yyy')

and in PHP8, we now get flooded with warnings "Undefined array key", which get in the way of real warnings.
Migrating and testing this code will take a long time, and furthermore, it's really ugly and harder to read:
if (isset($_GET['xxx'))
or
if (isset($_GET['xxx']) && $_GET['xxx'] == 'yyy'))
to suppress this warning.

Instead, it would be better to have some sort of pragma in the main header
ini_set("array_key_missing_enotice", true);
ini_set ("error_reporting", E_ALL & ~E_NOTICE);

To me, it seems sensible that a defined associative array, with a key that isn't present (and may not be expected), should not be a warning, especially if it's being tested for with if().

It may also be worth treating undefined variables the same way.

Thanks for your help,

[damianwadley]

It's true this was one of the more controversial notice/warning promotions for 8.0, however a majority of the 63 people voting on the matter felt that the promotion was worthwhile. Going back on that decision now would be counter-productive.
https://wiki.php.net/rfc/engine_warnings

Note that you can still use the @ operator in PHP 8.
https://3v4l.org/P9Otd

Because the truth is that PHP cannot know whether code accessing an undefined array key is doing so out of negligence or laziness (no offense). Perhaps the author assumed that $_GET['xxx'] existed when they wrote it and the warning is pointing out a real potential problem. Perhaps it was done out of a desire to type less and the warning is a nuisance reminder of that fact. Only you as a human being can know, so PHP takes the more cautious approach of assuming the worst.

[RichardNeill]

Thanks for your comment. I can understand the reason for changing it, but PHP is normally exceptional because it is so good at backward-compatibility and type-juggling. As the author of the codebases concerned, I've relied intentionally on that designed, documented, and intuitive behaviour of PHP in everything I've written for 20 years, since PHP4. I've always assumed that associative arrays can have variable numbers of keys (including zero).

So, it would cost me a 1000 hours of needless effort to find and change and test and QA and git every instance, and the codebase would be harder to read for it afterwards.

So at the moment, I've got 4 options, all bad.

• permanently stay on PHP7x
• permanently disable warnings
• fork PHP and maintain a patch
• incur months of busy-work.

I'm sure I'm not the only one this would affect.
So, that's why I'm suggesting a config option to change this, so that we can have it both ways.

[KapitanOczywisty]

Not recommended, because it will bite you in the ass, but you can set error handler to filter that warning:

<?php
set_error_handler(function($errno, $error){
    return str_starts_with($error, 'Undefined array key');
}, E_WARNING);

[RichardNeill]

Thanks Kapitan, that's really, really helpful. At least now I can see a way to avoid a migration problem.

For others who come across this problem, here is a more complete way of doing this, which preserves the error message, but demotes it back to a notice.

set_error_handler(function($errno, $error){
    if (!str_starts_with($error, 'Undefined array key')){
        return false;  //default error handler.
    }else{
        trigger_error($error, E_USER_NOTICE);
        return true;
    }
}, E_WARNING);

And one may wish to ignore the errors in production, with:

ini_set ("error_reporting",  E_ALL & ~E_NOTICE & ~E_USER_NOTICE);	

I've also added this as a note here, so that it helps others:
https://www.php.net/manual/en/migration80.incompatible.php

[kripper]

Please reopen this feature request or provide some alternative respecting our point of view about how we want to code our software.

The voting was wrong. Even when 51% prefer to mess up their code, it's not fair nor necessary to force the rest of us to do the same. We have read all your reasons, but we are still pretty sure you are wrong.

There are many brilliant developers who love PHP because you can write things as easy as:

if($arr['user']['name']) {
}

It's perfectly ok to assume that an undefined key and any sub-element will return NULL or any other value that casts to FALSE without throwing a WARNING. If we would care about the value, we would explicitly use isset().
We are not afraid about misspelling a key name. It was never a problem for us, but your decission infuriates us.

We have been sitting on old PHP versions for years because we refuse to sacrifice PHP's original simplicity.
Otherwise, we would probably be coding in C# / .NET

We also don't want to rewrite code to please you, because we don't even agree with you.

Please add this feature or we will have to fork and split the PHP community.

[RichardNeill]

Hi kripper,

If you put the code-block below into one of your common header files, you'll get what you want, i.e. demoting the warning back to a notice. It's now E_USER_NOTICE rather than E_NOTICE but otherwise, it reverts the old behaviour for that class of message. You can adapt the code to handle other unwanted errors, such as 'Undefined variable' depending on how far you want to take this.

//PHP-8 compatibility and migration.                    //PHP-8 has many new errors. Some (at least "undefined array key") now raise warnings.
if (version_compare(PHP_VERSION, '8') >= 0) {
        ini_set ("error_reporting",  E_ALL & ~E_NOTICE & ~E_USER_NOTICE);                       //Errors below are now USER_NOTICE, not NOTICE.
        set_error_handler(function($errno, $error){                                             //Custom error handler for WARNINGS.
                if (str_starts_with($error, 'Undefined array key')){                            //   * Demote "Undefined array key" back to notice. This shouldn't be a warning.
                        trigger_error($error, E_USER_NOTICE);
                }elseif (str_starts_with($error, 'Trying to access array offset')){             //   * Demote array-offset errors to notice.
                        trigger_error($error, E_USER_NOTICE);
                }else{  //use default error handler most of the time.
                        return false;
                }
                return true;
        }, E_WARNING);
}

[kripper]

Hi @RichardNeill,

Yes, that's what we all are doing, but the big problem are the exceptions when accessing undefined variables.

[omocinteractive]

What used to make it easy to get started with PHP now falls flat on your face after almost 20 years. It's really annoying when projects have grown over the years without having had the time to adapt the source code. For months I've been spending my time reworking the code - which no client pays for. I think I am not alone in this. I'm still waiting for the day when procedural programming in PHP is switched off ...

[kripper]

What used to make it easy to get started with PHP now falls flat on your face after almost 20 years. It's really annoying when projects have grown over the years without having had the time to adapt the source code. For months I've been spending my time reworking the code - which no client pays for. I think I am not alone in this. I'm still waiting for the day when procedural programming in PHP is switched off ...

Yeah. We all feel your dissapointment. Some developers here didn't appreciate PHP's simplicity and took a very bad decission.
As @RichardNeill pointed out above, you should write your own error_reporting callback and do some minor modifications.
For instance, we had cases of count(NULL) throwing fatal errors, so we had to create a function to force conversion from NULLs to arrays.
Let's hope backwards compatibily will be respected in next versions.

[omocinteractive]

What is the performance like with suppressed error messages? I once read that this can have a negative effect, even if they are not displayed.