Можно ли отключить/скрыть уведомления PHP?

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

Ближайшая вещь к ответу, который я мог найти, был в этом вопросе, но который еще далек от ответа, который я ищу. Есть ли какой-то непредвиденный недостаток, чтобы скрыть все уведомления, которые генерирует PHP? Например, чтобы включить переменную из POST-запроса обратно в форму, потому что были ошибки, я просто использовал бы:

<?= $_POST['variable'] ?>

Это создаст уведомление PHP. Чтобы исправить это уведомление, я мог бы использовать что-то вроде этого:

<?= isset($_POST['variable']) ? $_POST['variable'] : '' ?>

Но это действительно необходимо? Будет ли мой код на самом деле выгоден от этого, а не просто повторять переменную независимо от того, существует она или нет и потенциально создает уведомление PHP? Мне кажется, что возможность игнорировать уведомления - это преимущество использования PHP, так как тогда вам не нужно беспокоиться о том, определена ли переменная или нет, особенно для примера, такого как это, где это, похоже, не имеет значения.

Я также использую способность PHP автоматически изменять тип переменной/кастинг в зависимости от того, как она используется, и вы часто найдете фрагменты кода, такие как:

for ($i = 0; $i < $limit; $i++) $results[] = $i; // Example

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

$data = stdClass; // For reference, in my case this would be defined before this code
$data->results = array();
$limit = 0;
for ($i = 0; $i < $limit; $i++) $data->results[] = $i;
print json_encode($data);
// {"results":[]}

против

$data = stdClass; // For reference
$limit = 0;
for ($i = 0; $i < $limit; $i++) $data->results[] = $i;
print json_encode($data);
// []

Вопрос еще раз: какую реальную выгоду, если таковая имеется, я получу от исправления ошибок извещения, а не просто подавления их? Как это может повредить мой код?

Ответ 1

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

Предположим, что у вас есть переменная, которую вы хотите повторить, как в приведенном выше примере. Да, использование isset немного сложнее, но, возможно, ваше приложение должно обрабатывать специальный пустой случай, тем самым улучшая его. Пример:

if (isset($var)) {
    echo $var;
} else {
    echo "Nothing is found. Try again later.";
}

Если у вас был только echo $var;, и если это было общедоступное представление, которое читал пользователь, они ничего не видят там, что может вызвать путаницу. Конечно, это только один частный случай, когда исправление PHP-уведомлений может улучшить ваше приложение.

Это не следует воспринимать как проблему или неудобство, когда вы заботитесь о уведомлениях в PHP-коде, потому что код должен быть чистым. Я бы предпочел иметь бесплатный код, чем видеть чистый код, когда я его открываю в источнике. Конечно, и то, и другое определенно лучше!:)

Опять же, ошибки (даже если они не смертельны) вызовут проблемы в будущем. Если вы уже делаете такие вещи, как echo $var;, не проверяя это, это предположение о том, что существует переменная, даже если вы знаете, что это не так, она просто даст вам привычку предполагать вещи и Работа. Сейчас это может быть небольшим, но через некоторое время вы обнаружите, что у вас возникнет множество проблем.

Заметки есть по какой-то причине. Если мы все сделали error_reporting(E_ALL ^ E_NOTICE) в нашем коде, мы просто безответственно для нашего кода. Если вы можете это исправить, тогда почему вы ленитесь и не делаете этого? Конечно, корабль 1.0 с уведомлениями, исправить их позже, что мы все говорим. Но лучше сделать это как привычку, код в первый раз. Если вы потратили 15 минут на написание кода, преследуемого уведомлениями, а затем потратите 2 часа на более поздний срок разработки, исправив их, почему бы просто не потратить полтора часа на совершенствование кода, когда вы его пишете в первую очередь?

Написание хорошего кода должно быть привычкой, а не неудобством. Сообщения об ошибках приведены по какой-либо причине. Уважайте их, исправляйте, и там вы идете, вы ответственный программист.

Вы также проложите путь для будущих сопровождающих вашего кода.

Ответ 2

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

IMHO, предупреждения не следует игнорировать. Вы должны всегда следить за предупреждениями, чтобы предотвратить ошибку. Каждый раз, когда у меня есть уведомление в моем файле журнала, я рассматриваю его как ошибку.

Кроме того, если ваш сайт доступен большому количеству пользователей, вы получите очень большой файл журнала.

Ответ 3

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

Конечно, компьютеры не все настолько умны, и будут случаи, когда код достаточно ясен, и вам все равно, есть ли какие-либо предупреждения, но для чего нужен оператор @.

Ответ 4

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

public function foo ($array) {
    if (isset ($array[0])) {
        $bar = $array[0];
    } else {
        $bar = null;
    }

    // do something with $bar
}

функционально идентична

public function foo ($array) {
    $bar = @$array[0];

    // do something with $bar
}

но IMHO менее читабельна и больше работает для ввода. В этих случаях я знаю, что существует ровно две возможности: задана переменная или нет. Я не знаю заранее, но я должен действовать в обоих случаях. В этом случае я не вижу ничего плохого в использовании @. Да, вы также можете написать

public function foo ($array) {
    $bar = isset ($array[0]) ? $array[0] : null;

    // do something with $bar
}

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

Конечно, если я не ошибаюсь, использование @занимает немного больше времени для выполнения теста isset-test, но пусть честно: насколько наш код действительно критичен по производительности? В цикле, который выполняется в bazillion раз, я бы, вероятно, использовал isset вместо этого, но в большинстве случаев он не имеет никакого значения для пользователя.