Использование тернарного оператора ?: с подавлением ошибки?

Question

[Владимир]

Нормально ли использовать $c = @$a ? : 'default';вместо$c = isset($a) ? $a : 'default';?

И вроде ошибка, всего лишь, уровня E_NOTICE, а @ смущает все равно. С другой стороны — удобно же!

Кто как считает?

UPD1: Так как empty() игнорирует неопределенную переменную, а «Таблица сравнения типов в PHP» говорит, что !empty() полностью соответствует нестрогому булеву, то корректнее была бы замена:$c = !empty($a) ? $a : 'default'; на $c = @$a ? : 'default';
UPD2: (так как никто не читает уточнения). Рассматриваются, как основные варианты, так же доступ к неопределенным ключам массивов и магическим свойствам объекта, которые могут быть заданы извне.

$e = !empty($array['doubtful']['element']) ? $array['doubtful']['element'] : 'default';
// and
$e = @$array['doubtful']['element'] ? : 'default';

$p = !empty($object->magicProperty) ? $object->magicProperty : 'default';
// and
$p = @$object->magicProperty ? : 'default';

Comments

[Владимир]

Примеры использования:

$v = !empty($viewVariable) ? $viewVariable : 'default';
// and
$v = @$viewVariable ? : 'default'; //one pity IDE definition warning

$e = !empty($array['doubtful']['element']) ? $array['doubtful']['element'] : 'default';
// and
$e = @$array['doubtful']['element'] ? : 'default';

$p = !empty($object->magicProperty) ? $object->magicProperty : 'default';
// and
$p = @$object->magicProperty ? : 'default';

[Владимир]

Такие моменты вынужденной проверки предположительно не инициализированных переменных возникают, в основном, из устарелого кода, внешних (не задокументированных) источников данных, магии и прочего отсутствия профессионализма разработчиков.
Например:
Самопальный фреймворк, наследие php4, тяжелые попытки перехода на ООП и MVC парадигму. В контроллерах магические свойства получают данные запроса. Контроллеры передаются аргументом на обработку во всяческие менеджеры, где могут быть изменены их (магические опять же) свойства.
Это очень печальные примеры. И хотелось бы больше никогда не встречать такого на практике, но изначально ошибки уровня «Переменная не инициализирована» просто игнорировались на уровне error_reporting(E_ERROR) и никакая проверка не проводилась. Разработку вести с такой директивой совесть не позволяет. Поэтому пришлось расставлять проверки. Но это выявило лексическую тяжбу в PHP, которую хочется решить наиболее удобным методом.

Answer 1

[Артур Борденюк]

Предпочитаю не допускать даже E_NOTICE

Comments

[Владимир]

Он и не допускается. Намеренно. Задокументированными возможностями. То, что такой метод выглядит и воспринимается, как костыль и породило вопрос.

[Stdit]

Это сознательное допущение E_NOTICE. Умалчивание ошибки не означает, что ее там нет. И когда там возникнет E_WARNING, или любая другая, не предусмотренная ранее ошибка, в логах тоже ничего не будет. В этом заключается опасность использования «собаки».

[Владимир]

Возникновение E_WARNING в таком контексте требует примера отличного от «когда там возникнет».

Answer 2

[PaulZi]

На сколько я знаю подавление ошибки собачкой существенно замедляет код. Поправьте меня если я неправ.

Comments

[m-haritonov]

Похоже, время выполнения кода с собакой действительно в несколько раз медленней (php 5.4.13):

$startTime = microtime(true);
for ($i = 0; $i <= 10000; $i++)
{
	(isset($_GET['aaa']) && $_GET['aaa'] == 'abc');
}
print number_format(microtime(true) - $startTime, 10) . "\r\n";
// 0.0010221004 секунд


$startTime = microtime(true);
for ($i = 0; $i <= 10000; $i++)
{
	(@$_GET['aaa'] == 'abc');
}
print number_format(microtime(true) - $startTime, 10) . "\r\n";
// 0.0060720444 секунд

Если проверяемая переменная инициализирована (и сообщение об ошибке не генерируется), то разница в скорости незначительна:

$_GET['aaa'] = 'abc';

$startTime = microtime(true);
for ($i = 0; $i <= 10000; $i++)
{
	(isset($_GET['aaa']) && $_GET['aaa'] == 'abc');
}
print number_format(microtime(true) - $startTime, 10) . "\r\n";
// 0.0012769699 секунд


$startTime = microtime(true);
for ($i = 0; $i <= 10000; $i++)
{
	(@$_GET['aaa'] == 'abc');
}
print number_format(microtime(true) - $startTime, 10) . "\r\n";
// 0.0018811226 секунд

[Владимир]

Еще вычитаем на дополнительную инструкцию в сокращенном операторе ?:

[Владимир]

<?php

ini_set('memory_limit', '512M');
error_reporting(E_ALL);
class test {
    static $current;
    static $emits;
    static $times = [];
    static function start($n){
        self::$current = $n;
        self::$emits[$n]=[];
        self::$times[$n] = microtime(1);
    }
    static function stop($n){
        self::$times[$n] = microtime(1)-self::$times[$n];
    }
    static function emit($v){
        @self::$emits[self::$current][(int)!!$v]+=1;
    }
}
class magic
{
    protected $p = [];
    function __get($name)
    {
        return $this->p[$name];
    }
    function __set($name, $value)
    {
        $this->p[$name] = $value;
    }
    function __isset($name)
    {
        return isset($this->p[$name]);
    }
    function __unset($name)
    {
        unset($this->p[$name]);
    }
}
$len = 1000000;
$Object = new magic();
$Array = [];
for ($i = 0; $i < $len; $i++) {
    if($i%3){
        $Object->{'p' . $i} = $i;
        $Array[$i] = $i;
    }
}

//normal section
$test = 'normalWithObject';
test::start($test);
for ($i = 0; $i < $len; $i++) {
    $n = 'p' . $i;
    test::emit(!empty($Object->{$n}) ? $Object->{$n} : false);
}
test::stop($test);

$test = 'normalWithArray';
test::start($test);
for ($i = 0; $i < $len; $i++) {
    test::emit(!empty($Array[$i]) ? $Array[$i] : false);
}
test::stop($test);

//abnormal section

$test = 'abnormalWithObject';
test::start($test);
for ($i = 0; $i < $len; $i++) {
    test::emit(@$Object->{'p' . $i} ? : false);
}
test::stop($test);

$test = 'abnormalWithArray';
test::start($test);
for ($i = 0; $i < $len; $i++) {
    test::emit(@$Array[$i] ? : false);
}
test::stop($test);

print_r(test::$times);

Array
(
    [normalWithObject] => 1.6597728729248
    [normalWithArray] => 0.46078515052795
    [abnormalWithObject] => 1.5833020210266
    [abnormalWithArray] => 0.70977306365967
)

[Владимир]

Плюс, доставание значения из многомерного массива будет выполнено с немного большим профитом, нежели обычным методом. Не тратится время на проход.

Answer 3

[larikov]

$a = 0;
$c = @$a ? : 'default';

$a = 0;
$c = isset($a) ? $a : 'default';

Могут вылезти трудноуловимые глюки. К примеру, чему будет равно $c в первом и втором случае? :)

Comments

[Владимир]

Тогда UPD как замена

$c = !empty($a)?$a:'default';

[larikov]

И приходим к тому, что переменная $a должна быть инициализирована :)

[Владимир]

Эта логика привела Вас к причине возникновения «короткого костыля» вместо «костыля». Но вопрос остался. Т.к., переменная может и не быть инициализирована. Мир кода не идеален :)

[larikov]

Если переменная не инициализирована, возможно что-то не так с кодом.

[Владимир]

Это не сопряжено с кодом PHP на таком уровне, который мог бы дать однозначный ответ на вопрос «Все ли „так“ с кодом, в котором переменная может быть не инициализирована?».
Могу, с упреждением, ответить, что кодовая база, с которой приходится работать и использовать конструкции вроде приведенных в вопросе, далека от идеала. Много массивов, много невыясненого/неявного поведения, магических свойств и тому прочего. Вот и приходится.

Answer 4

[Александр]

Это не нормально. К E_NOTICE следует относиться как к настоящей ошибке.

Comments

[Владимир]

Тогда встречный вопрос. Зачем нужна эта штука @? Я читал документацию. Рекомендаций по использованию только на этапе разработки и дебага не видел.

[m-haritonov]

@kruoz, использовать оператор "@" для устранение замусоривающих конструкций, вроде:

if (!isset($a))
	$a = null;

вполне нормально (на мой взгляд).

[Владимир]

Я допускаю, что частные проблемы вбросов ошибок некоторыми функциями (которые можно решить патчем на уровне error_handler) будут решены раньше, чем оператор @ будет объявлен неправомерным:)

[m-haritonov]

OnYourLips, вот как раз перед вызовами функций этот оператор использовать и не следует, т.к. он подавит так же и полезные сообщения об ошибках (например, об отсутствии прав доступа к файлу). Лучше преобразовать warning'и в исключения через set_error_handler и отлавливать их.

[m-haritonov]

OnYourLips, касательно fsockopen (и некоторых других сетевых функций) — согласен (к тому же, данная функция присваивает код и строку ошибки переданным ей аргументам). Касательно unlink: недоступность файла для удаления — это уже именно ошибка, а не вариант предполагаемого поведения (т.к. локальная файловая система находится в вашем ведомстве).

Оборачивать каждую функцию своим хендлером и потом его снимать — то еще извращение.

Я имел ввиду навесить хандлер один раз для всего кода. Но, вынужден признать, что это решение не подойдёт, если используются сторонние библиотеки, не совместимые с подобным поведением.

[m-haritonov]

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

[Александр]

Тогда встречный вопрос. Зачем нужна эта штука @? Я читал документацию. Рекомендаций по использованию только на этапе разработки и дебага не видел.

Это можно считать устаревшим оператором, костылём. В хорошем коде по идее его быть не должно.

if (!isset($a))
$a = null;

isset несколько громоздок, я бы как раз хотел, чтобы у него был 1-символьный алиас, но вообще я не припомню случая, чтобы к примеру вот так потребовалось инициализировать переменную.

вот как раз перед вызовами функций этот оператор использовать и не следует, т.к. он подавит так же и полезные сообщения об ошибках (например, об отсутствии прав доступа к файлу). Лучше преобразовать warning'и в исключения через set_error_handler и отлавливать их.

Совершенно верно. Удобно, когда все ошибки выбрасывают исключения. Любой современный фреймворк так работает.

Answer 5

[shushu]

А я бы сделал так:

function getOrDef($val, $def = 'default')
{
    return !empty($val) ? $val : $def;
}

$a = getOrDef($a, '234');

Comments

[truezemez]

Будет нотис:

$a = getOrDef($_GET['a'], '234');

[m-haritonov]

shushu, и чем это отличается от записи:

$a = $a ?: '234';

?

[shushu]

truezemez, согласен, не подумал про массивы.
mkharitonov, тем что не генерится ошибка. И не нужно каждый раз писать если не пустое то ЭТО иначе ТО. немного лаконичней.

[m-haritonov]

Ошибка (E_NOTICE) в Вашем примере генерироваться будет, т.к. переменная $a предварительно не объявлена.

[Владимир]

В принципе, основная причина возникновения такого «костыля» у меня в уме, это работа с непредсказуемым состоянием массивов и магических свойств объектов.
Есть ряд готовых решений для доставания значения из массива или заменой его значением по-умолчанию.
Во многих решениях даже поддерживается dot notation (вложенность пути через точку)
Например у kohana

$val = Arr::path($arr, 'get.some.inner.value','or other');

Но это совсем не быстрее этого

$val = @$arr['get']['some']['inner']['value']?:'or other';

Удобно? Быстрее?
Пример с магическими свойствами объекта приводить не стану.

[m-haritonov]

И не нужно каждый раз писать если не пустое то ЭТО иначе ТО

Конкретно в приведённом мной примере это и не пишется. Логика $a = $a ?: '234'; сейчас идентична логике Вашей функции.

[Владимир]

Что странно. Большинство высказываний было в сторону того, что в будущем может поменяться какая-то логика и вернется не E_NOTICE, а E_WARNING, но это же совсем не культурно менять логику поведения, например offset'а для массивов:)

[m-haritonov]

lazycommit, плюс подобные самописные способы доступа к массиву не поддерживаются автодополнением IDE и требуют от программиста, читающего код, дополнительных знаний о нестандартном синтаксисе.

Answer 6

[try4tune]

Использование @ — это очень плохой стиль программирования. Кроме случаев с подавлением вывода ошибок стандартных функций (fopen, fsockopen, ...). Этот оператор не избавляет от ошибки, а просто скрывает ее вывод. Очень не рекомендую. Говорю как ZCE.

Answer 7

[rozhik]

Это $c = @$a?: 'default'; и $c = isset($a)? $a: 'default'; разный код. Посмотрите разницу на 0, '', "\0", false и еще много чем, которое преобразуется в boolean FALSE. По этому нотис вполне верен, учитывая, что на разных версиях PHP будет работать по разному.

Comments

[Владимир]

Да. Все верно. Изначально вопрос был сформирован некорректно. См. UPD

Answer 8

[m-haritonov]

У меня на PHP 5.3.16 при выполнении кода $c = @$a ? : 'default'; никаких E_NOTICE не выдаётся. Возможно, у Вас установлен свой обработчик ошибок (через set_error_handler), который игнорирует оператор "@".

Comments

[Владимир]

Предполагаю, что вы неверно истолковали вопрос. Оператор @ для того и был использован, чтобы подавить E_NOTICE.

[m-haritonov]

А в чём тогда был вопрос? Вы хотите обойтись без оператора "@" вообще?

[m-haritonov]

Кажется понял. Вопрос был в том, нормально ли использовать оператор "@" перед переменной для подавления сообщения о неинициализированной переменной?! Если так, то да, нормально (на мой взгляд).

[Владимир]

Хочу заменить «замусоривающие конструкции» более короткими с использованием @. Где это допустимо, конечно.

[m-haritonov]

Тогда повторюсь, что я не вижу причин почему это не допустимо. Только ограничиться, на мой взгляд, стоит использованием данного оператора лишь совместно с внешними переменными (@$_GET, @$_FILES, $@_SERVER и т.п.) и лишь ради исключения замусоривающих конструкций if (!isset($_GET['a'])) $_GET['a'] = null;. Директива register_globals в PHP 5.4 удалена полностью, поэтому с ней проблем больше нет. Обычные переменные, размещённые в глобальной области видимости, следует всё же инициализировать всегда, чтобы исключить случайную инициализацию в каком-либо из подключённых файлов.

Answer 9

[Stdit]

Неудивительно, что вас смущает использование «собаки», нутро верно подсказывает, что это — умалчивание ошибки и во многих случаях используется как костыль. А isset, empty и is_null — это очевидная логика, причем разная, и более чистый и понятный код. Я бы рекомендовал забыть что «собака» вообще существует, пока нужда остро не прижмет в каком-нибудь стареньком проекте.

Comments

[Владимир]

При всем моем желании отказываюсь верить, что @ является костылем на уровне языка )

[Stdit]

А зря. Мне этот оператор изрядно попортил настроение при попытке отладки старенького сайта по логам. Особенно когда он ставился перед файловыми операциями вместо file_exists.

[Владимир]

Это камень в огород касательно использования его перед вызовами. И я с вами полностью согласен. В данном же случае они не рассматриваются.

[Stdit]

«Собака» — это грязный хак для очистки логов от сознательно допущенных ошибок. Беда в том, что она блокирует все ошибки, как предусмотренные, так и нет. И даже если сейчас все будет казаться нормально и надежно, нет никаких гарантий, что эта «собака» не подпортит кому-то жизнь через пару лет, например при отладке своим логгером, каким-нибудь профайлером, или при обновлении php. Поэтому я стараюсь избегать ее всеми возможными способами, и контролировать именно то, что собираюсь контролировать, даже если для этого надо написать еще несколько символов.

Answer 10

[m-haritonov]

Этот оператор не избавляет от ошибки, а просто скрывает ее вывод.

Собственно, это и утверждается в документации. И в случае с размещением этого оператора перед $_GET['aaa'] именно игнорирование предупреждения о неинициализованой переменной и требуется, т.к., в соответствии с предназначением данного массива, его значения приходят из вне, а не объявляются внутри программы и отсутствие предупреждений было бы уместнее, т.к. иначе приходится писать дополнительный код, которые не несёт в себе полезной нагрузки.

Очень не рекомендую. Говорю как ZCE.

Может, как ZCE, лучше скажите, почему Вы не рекомендуете его использовать? А то сейчас Вы обошлись простым «Это плохо, понятненько?!».

Answer 11

[Alex Kheben]

Из прочтённых комментариев я так и не понял, на сколько (не)кошерным является @. Правда это уже не по теме самого вопроса, но всё же.

На сколько кошернее такой вариант:

if (!empty($_POST[qty])) $qty = (int) $_POST['qty'];
else return false;

Чем этот:

if (!@$qty = (int) $_POST['qty']) return false;

Второй, на мой взгляд, проще (ИМХО).

Я не супер-гуру в PHP, но понимаю, что можно решить такую задачу через какую-нибудь абстракицю, хотя бы в виде функции, для увеличения гибкости рабочего решения.

Comments

[Владимир]

Согласен полностью, по сути empty является обычным перевернутым «оператором» булевого нестрогого сравнения с игнорированием ошибки неинициализированной переменной и его использование в контексте «либо переменная, либо другое значение» очень удобно с тернарным оператором, но невозможно, поскольку возвращает булево, а не значение.

[m-haritonov]

zBit, empty лучше не использовать, т.к. она возвращает true для строки «0» (вместо empty лучше использовать проверку на пустую строку: @$_POST['qty'] == ''). Второй пример кода, на мой взгляд, хуже, т.к. я считаю, что использование присвоения в выражении условия ухудшает читабельность кода. Плюс, примеры кода у Вас не равнозначны.

[Alex Kheben]

empty лучше не использовать, т.к. она возвращает true для строки «0»

Мне именно так и надо. Если количество 0 || NULL || '', то не делать ничего.

Плюс, примеры кода у Вас не равнозначны.

Ткните носом, пожалуйста =)

[m-haritonov]

Во-первых, отличается структура условного оператора (во втором примере нет else, из-за чего он короче). Если использовать структуру условного оператора, соответствующую второму примеру, то код должен выглядеть так:

if (empty($_POST['qty']))
	return false;

$qty = (int) $_POST['qty'];

Во-вторых, для полной равнозначности, вместо empty надо использовать такую же проверку, как и во втором примере (иначе, если $_POST['qty'] будет равен «0.0», «000», " 0 " и т.п., то результат сравнения будет отличаться для двух Ваших примеров):

$qty = isset($_POST['qty']) ? (int) $_POST['qty'] : 0;
if (!$qty)
	return false;

P.S.: в первом примере у Вас также написано $_POST[qty] вместо $_POST['qty'], т.е. используется значение константы (и лишь из-за того, что такая константа не определена, используется её имя, а не значение).

[Alex Kheben]

$_POST[qty] вместо $_POST['qty']

Так и знал, что кто-нибудь, да придерётся. Понятно же, что это опечатка.

[m-haritonov]

Так и знал, что не надо было об этом писать, т.к. это опечатка. :)

Answer 12

[m-haritonov]

… удалено (не туда разместил)...