2012-02-08 2 views
3

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

Это произошло со мной, и внутри графа объектов, где есть некоторые учетные данные, и другие вещи, которые вам обычно не понравится конечному пользователю. Проблема заключалась в том, что вместо того, чтобы передавать true как второй параметр, по какой-то причине я передал null 1 год назад. И теперь произошел сбой в системе, который сделал неправильное отображение вывода.

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

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

Обычно мы используем какую-то буферизацию вывода, но не везде.

+0

Либо будьте осторожны с 'print_r()' или напишите какую-либо функцию-оболочку для 'print_r()', которая никогда не будет эхом. ;) – Crontab

+0

@Paul, вы можете [переопределить 'print_r' и' var_export'] (http://stackoverflow.com/a/2640992/632951), чтобы он плюнул на журнал ошибок независимо от второго аргумента. – Pacerier

ответ

3

Почему бы не создать пользовательскую функцию, которая будет обертывать все ваши звонки print_r? Я использую что-то вроде этого:

function good_print() { 
    $log = ''; 
    foreach(func_get_args() as $arg) $log .= print_r($arg, true); 
    return $log; 
} 

Это экономит время, дает мне лучшую функциональность, плюс я не придется беспокоиться о «я использовать правильный вызов на этот раз?»

+1

+1 для чтения вопроса;) – rdlowrey

+0

Да, это то, что мы сделали. Мы уже использовали функцию отладки (обертку для Zend_Log), и теперь мы изменили параметр из строки на несколько параметров, которые затем конкатенируются и сбрасываются правильно (логическое значение как true, false, null как null, struct as print_r). Это было вдохновлено функцией javascripts console.log. –

+0

Ницца, это звучит как сплошное решение – davethegr8

1

В соответствии с ручными документации PHP на print_rdocs, вы можете сказать, print_r возвращать результаты вместо того, чтобы выводить их со вторым, дополнительным параметром BOOL:

$test = array('var1', 'var2'); 
$val = print_r($test, TRUE); // won't output anything 
echo $val; // output the normal print_r goodness you know and love 

UPDATE

После на самом деле Читая вопрос, я бы предложил решение @ davethegr8, чтобы вы и другие люди, вероятно, голосовали за это по этому поводу. Другая реализация:

function _print_r($val, $return=TRUE) 
{ 
    print_r($val, $return); 
} 

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

+0

", и иногда я забываю установить второй параметр в true" – davethegr8

+0

Хм, когда я читаю ваш фактический вопрос, а не только название, кажется, вы это знали. Я с @Crontab - вам нужно быть осторожным, оставляя 'print_r' случайным образом лежащим в вашем коде. – rdlowrey

1

Что вы делаете, чтобы избежать ошибок в стеке, вызванных ошибкой программиста?

Простой, не код производства не допускается производство (var_dump, print_r и др. Никогда не полезны в производстве). Обеспечьте в порядке предпочтения либо систему сборки/тестирования, либо систему управления версиями, обеспечивающую использование только функций-оберток, которые можно легко отключить централизованно или, если необходимо, конфигурацию производственного сервера.

Почему все функции демпинга PHP только эхо выводит по умолчанию?

Потому что это самое легкое в течение развития.

Поиска хотя наш кодовый, я нашел довольно много призываний print_r без второго набора параметров для истинного

И вы также нашли много or die('some errormessage); заявлений, также не очень хорошую идею в производстве по очевидным причинам. Ручной код - это иллюстрация, а не производственный код, но, к сожалению, многие программисты.

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

Некоторые дополнительные нагрузки, может быть, и не ясно, что индикатор для отладки (как уже упоминалось ранее, var_dump красный флаг, json_encode нет).

Обычно мы используем какую-то буферизацию вывода, но не везде.

Я использую его только в тех случаях, когда это необходимо, поэтому почти нигде.

+0

+1 для * «Принудительно использовать систему сборки/тестирования, контроль источника» * – rdlowrey

+0

Хорошо, я забыл упомянуть, что вызов «злой» print_r был законным logging, поэтому мы знаем, что это недопустимое значение. –

3

var_export() возвращает строку, если второй аргумент истинен; но это до вас, чтобы помнить, чтобы установить, что второй аргумент

+1

print_r() это тоже ... проблема не в том, чтобы забыть установить эту строку. –

0
What do you do to avoid having stacktraces output by programmer error? 

вы можете установить пользовательские METHODE, что печать ошибки, только если параметр DEBUG установлен

define('DEBUG', "DEBUG"); 

function print_log($input) { 
    if (defined("DEBUG")) { 
     print_r($input, true); 
    } 
} 

и вместо вызова print_r просто позвонить print_log.

вы также можете взглянуть на Krumo, что является удивительной заменой для var_dump и print_r путем отображения PHP-переменных структурированным способом.

Смежные вопросы