Является ли это плохой практикой использования оператора подавления ошибок?

Question

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

Определен метод sanitise, который пытается очистить пользовательский ввод как можно лучше, но я пытаюсьВырежьте код, который проверяет существование переменных POST и GET, и код для определения переменных со значениями по умолчанию, если они не существуют.

Это то, что я придумал, но это оставляет мой неприятный вкуси другие разработчики говорят, что мы все чувствуем, что оператор подавления ошибок злоупотребляет:

$Page      = sanitise(@$_GET["page"], "Unspecified");
$Timestamp = sanitise(@$_POST["time"], time());

Пожалуйста, не могли бы вы дать мне некоторую критику этого кода?Это не идеально, я согласен, но это сокращает много кода и намного более читабельно, чем то, что у нас было.

В одной строке я попытался добиться следующего:

1. Проверка существования переменной.
2. Если она существует, очистите входные данные и назначьте переменную.
3. Если она не существует, создайте переменную, но используйте значение по умолчанию.

Как вы думаете?

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

Answer 1

Использование оператора @ обычно считается плохой практикой.

В вашем случае этого можно избежать, разделив вещи на несколько шагов:

• проверка установки переменной - с помощью isset()
• работает над этим - или нет:
  • если установлено, очистить его
  • иначе, используя значение по умолчанию.

Поскольку оператора @ можно избежать, здесь ... ну, я бы его избежал.

Примечания:

• маскирование ошибок, как правило, не очень хорошая идея (в этом случае это не должно сильно навредить ... но, тем не менее)
• и оператор @ имеет стоимость, если говорить о выступлениях ¹ .
• однострочники не обязательно должны быть целью; -)

^1. _{Но некоторые скажут, что это не так уж важно - и они, вероятно, правы}

Answer 2

Сохраните немного кодирования и создайте класс "Input" с несколькими статическими функциями, например:

class Input {

      public static function get($key, $default = null)
      {
            return (array_key_exists($key, $_GET)) ? $_GET[$key] : $default;
      }

      // same thing for $_POST...

}

Тогда вы можете вызвать свою функцию sanitize следующим образом ...

sanitize(Input::get('page', 'Unspecified'));

Answer 3

Вы можете использовать оператор terany для проверки существования, избегая использования оператора подавления ошибок:

$Page = (!empty($_POST['test'])) ? $_POST['test'] : 'default';

Обычно использование оператора подавления рассматривается как плохая практика, поэтому использование оператора terany, как этот, будетИзбегайте подавления ошибок, а также дайте желаемый эффект.

Answer 4

В целом остальные ответы верны.Существуют проблемы с использованием @, чтобы просто притвориться, что ошибок не существует.

Тем не менее, в этом случае я бы использовал ваш подход.Он разборчив, лаконичен и - в этом небольшом сценарии - просто выполняет работу .Мне трудно думать о потенциальных ошибках здесь.

Answer 5

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

Хороший способ это:

$Page = (isset($_GET['page'])) ? $_GET['page'] : 'default';
$Page = sanitise($Page, "Unspecified");

Но поскольку у вас есть функция sanitize (), вы можете обновить ее и сделать эту проверку за вас.

function sanitise($value, $default, $fromRequest=false)  {
 if ($fromRequest) $value = (isset($_REQUEST[$value])) ? $_REQUEST$value] : $default;
  ..
}

$ _ REQUEST - глобальная переменная, представляющая $ _GET + $ _POST + $ _COOKIE, но вы можете вырезать мою версию.

Answer 6

Чтобы избежать синтаксиса программирования культа груза с isset, я использую обертки объектов вокруг входных массивов. Он специально выполняет проверку за кулисами, поэтому я могу избежать и глупых исет и @.

Для вашего примера я бы написал $_GET->int->default("time", time())
или $_GET->sanitize["page"] и если все правила предопределены, просто $_GET["whatever"] с автоматической фильтрацией.

В противном случае я все еще буду использовать @ $ _ GET, потому что я не верю в кодирование внешнего вида.