Как избежать PHP Notice: Undefined offset?

Question

[Issue]

Занимаюсь отладкой сайта на Wordpress. Очень много самописных плагинов. При автоматическом рекурсивном проходе сайта - получил файл на 250 строк с ошибками Undefined offset: 0.
Я полагаю, необходимо писать условия:

if ( isset( $var[0] ) ){
        return $var[0];
}

Как правильнее будет исправлять подобные вещи?

Answer 1

[Rsa97]

Зависит от того, где и что должно возвращаться. Можно как $var[0] ?? null. А в идеале вообще не должно быть обращений к несуществующим элементам массива.

Comments

[Issue]

Это как в ответе ниже?

[Rsa97]

Issue, Не совсем. Повторю, всё зависит от того, что нужно делать. Возможные реакции - от игнорирования до выброса исключения.
return $var[0];

return $var[0] ?? null;

return $var[0] ?? DEFAULT_VALUE;

if (!array_key_exists(0, $var)) {
    throw new Exception('Data error!');
}
return $var[0];

[Vitsliputsli]

Issue,

Это как в ответе ниже?

Ни в коем случае, мы там увлеклись обсуждением конструкций.

В вашем случае, скорее всего, будет достаточно заменить на $var[0] ?? null. Исходя из того, что существующий код работает и вас устраивает. Интерпретатор, когда натыкается на несуществующую переменную, идет дальше используя null вместо этой переменной. Поэтому $var[0] ?? null должно быть достаточно.
Но это по-сути лишь подавление ошибок, нужно разбираться откуда эти обращения к несуществующему, а здесь уже нужно понимать логику. Собственно об этом Rsa97 и написал.

Answer 2

[Flying]

Например так:

if (($var[0] ?? null) !== null) {
  return $var[0];
}

Comments

[Ипатьев]

с какого это перепугу нельзя возвращать значения null?

[Vitsliputsli]

Роман Юрьевич Ипатьев, у автора так написано в примере.

Вариант с isset лучше, всего 1 функция, без ненужных жонглирований с присвоением null переменной.

[Ипатьев]

Vitsliputsli, согласен
Был настолько поражен этим бессмысленным нагромождением операторов, что забыл исходную задачу.

[Vitsliputsli]

Роман Юрьевич Ипатьев, это да, я тоже только сейчас понял, что обсуждаем не то, что решает задачу автора. Получилось, что я предлагаю вариант isset, а я как бы просто сравнил 2 конструкции, и совсем забыл про задачу.

[Александр]

Роман Юрьевич Ипатьев, люди поняли, что нул возвращать нельзя лет так 25 назад

[Vitsliputsli]

Александр,

люди поняли, что нул возвращать нельзя лет так 25 назад

Почему нет? Такой же тип данных, как и остальные. Что тип возвращаемых данных должен быть как можно уже - да, это удобнее, проще контролировать вариативность. Но удобнее, не значит нельзя.
К примеру, метод работающий с бд возвращает значение одной ячейки. Ячейка в базе имеет значение null, что в этом случае должен вернуть метод, если не null?
Так что, кто эти люди и что конкретно они поняли?

[Flying]

Vitsliputsli, На правах автора ответа всё-таки вклинюсь в вашу дискуссию.

В целом я признаю, что вариант не особо универсальный, поскольку оригинальный вопрос не содержал достаточной информации. Банально, оригинальный код применим и к ситуации, когда $var - строка, тогда логично было бы проверять if ($var !== '') { ... }, но я предположил более распространённый вариант когда $var - массив.

В этом случае корректным вариантом будет проверка существования индекса: if (array_key_exists(0, $var)) { ... }, но довольно быстро становится плохо читаемым, если вложенность глубже. isset() в случаях более глубокой вложенности тоже не работает, а вот null coalescing - работает, поэтому он и был предложен.

[Vitsliputsli]

Flying, корректный ответ на вопрос автора дал Rsa97.

if (array_key_exists(0, $var)) { ... }, но довольно быстро становится плохо читаемым, если вложенность глубже. isset() в случаях более глубокой вложенности тоже не работает, а вот null coalescing - работает, поэтому он и был предложен

null coalescing и isset не могут один работать, а второй нет. Они имеет одну и ту же проверку, т.к. первое - это сахар для второго. А вот array_key_exists совсем другое дело, она иначе реагирует на null.

[Александр]

Vitsliputsli, возвращение null заставляет вызывающий метод код всегда проверять его. Ты не застрахован, что на null будет проверено. Очень часто я встречаю код в котором возможность null в ответе вовсе не учитывается, хотя таковая есть. И без всяких проверок этот null гуляет дальше по коду, а потом когда все упадет через миллион строк кода, пойди найди как туда попал null. Запрет на возвращение null - защита от дурака в больших системах.

[Flying]

Vitsliputsli, Забавно, вы только что открыли мне глаза на то, что isset() нормально обрабатывает глубокие вложенности. Спасибо! Даже интересно почему я это пропустил в своё время...

Александр, Не согласен, иначе зачем null существует? Зачем существуют nullable типы? Если кто-то пренебрегает корректностью типов - то это не значит что не стоит пользоваться возможностями языка, скорее это повод для обучения такого человека или применения каких-то организационных мер в отношении него.

Кроме того, если говорить о современном PHP, а не о временах PHP 4 и 5 - то задача решается просто требованием везде формально определять типы аргументов и возвращаемых значений. Кроме того никто не мешает использовать статические анализаторы и определять типы, которые нельзя описать на уровне языка, через PHPDoc. В этом случае при забытой проверке вы получите либо сообщение от статического анализатора на этапе проверки либо TypeError (и связанный с ним stacktrace) в runtime. Ну и IDE очень хорошо проверяют это, тот же PHPStorm.

[Александр]

Flying, зачем существует goto? если не знаете про это, погуглите и узнайте почему это плохо. Но существовать это ему не мешает.

[Flying]

Александр, А почему это плохо? :) Может создателям PHP напишете, а то они не в курсе...

[Александр]

Flying, нет, я лучше скину вам вот это https://stackoverflow.com/questions/46586/goto-sti...
Ну или вы можете загуглить "why should goto be avoided?"

[Flying]

Александр, Спасибо, я в курсе, не первый год занимаюсь программированием :) Но речь, напомню, была о null, есть такая же ссылка про null?

[Александр]

Flying, https://levelup.gitconnected.com/never-return-null....

[Flying]

Александр, Весьма спорная статья. Я категорически согласен с комментариями от Miguel Cudaihl и, особенно от Andrew Ackerman.

Option pattern, не упоминающийся в статье - хороший вариант, но нативной его поддержки в PHP нет, хотя несложно сделать самому но это в целом усложняет проверку, а с учётом отсутствия в PHP дженериков - ещё и приводит к потере информации о типах без применения статических анализаторов.

[Vitsliputsli]

Александр, в принципе согласен, но повторюсь, дело не в null, а в слишком широком диапазоне возвращаемых типов. Все что вы описали справедливо будет и для любых других типов, когда от функции ожидается только определенные типы, а она возвращает иные. И абсолютно согласен, что очень часто встречается проблема именно с null, но это нисколько не умаляет возможность вернуть null там, где это необходимо и ожидаемо.