php отладчик

Судя по часто встречающимся на сайтах «mysql error» и «Fatal error» в php принята силовая отладка.

Там даже сокращённая форма вывода переменной есть, ЕМНИП.

xdebug же. Интегрируется с phpstorm и кучей других IDE.

phpdbg начиная с php 5.6 поставляется из коробки.

Сам не пользуюсь отладчиками, обхожусь var_export/var_dump.

Сам не пользуюсь отладчиками, обхожусь var_export/var_dump.

Я с некоторых пор перешёл в основном на (composer) digitalnature/php-ref и, реже, aronduby/dump c tracy/tracy.

Ещё интересен php-console/php-console.

Мне всё это неинтересно, ибо оно предназначено для традиционных проектов, где html генерируется пыхом. А я от этого уже давно отказался в пользу rest и json-rpc.

Все сообщения об ошибках и неперехваченные исключения всегда пишутся в лог. При дебаге можно отдать ещё json, хотя логи палить удобнее будет, на мой взгляд. Набрал в терминале tail -f resources/logs/*.log и всё.

Вот когда можно будет запускать похапешное приложение как в питоне, рубях, и других язычках, то скорее всего пригодятся какие-нибудь инструменты. Хотя в том же питоне мне для отладки достаточно написать import pdb; pdb.set_trace() в нужном месте.

А я от этого уже давно отказался в пользу rest и json-rpc.

И чем тогда var_dump поможет? :) Я же именно в его контексте писал.

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

Аналогично. Но это касается обычных юзеров. При print-debug'е удобнее видеть результат сразу после F5, а не лезть потом в логи.

И, да, я JSON и XML тоже часто отлаживаю. Для JSON вообще ничего менять не надо, а для чего-то типа XML/RSS можно или комментом пустить или временно поменять content-type.

Не вижу смысла во всех этих инструментах, которые прикручивают всякие тулбары, раскрашивают трейсбеки и всё такое прочее. Короче говоря, мне проще написать var_dump();exit(); чем думать как прикрутить всё это говно так, чтобы оно грамотно, без костылей взаимодействовало с фронтендом. А в случае, если клиент — не браузер, то оно вообще будет ненужно.

лезть потом в логи.

tail -f. Слева браузер, справа терминал. Жми f5 и наблюдай. Не вижу проблемы.

phpdbg кстати выглядит интересно, надо потыкать. Если оно работает так же, как и pdb в питоне, то с радостью перейду на него.

Короче говоря, мне проще написать var_dump();exit(); чем думать

Вот _именно поэтому_ мне по душе digitalnature/php-ref. Вместо твоего многословия пишется просто ~r(); :) При чём будет выдан не только выхлоп, но и имя переменной или строка с выражением, имя файла с номером строки — это актуально, когда таких выхлопов больше одного в коде, чтобы не путаться, какой где. А уже вопросы раскраски — вторичны. Хотя и они сильно помогают.

Опять же, за что нравится D::ump — за интеллект, типа, раскрутки даты при виде числа похожего на timesmamp. А тот же r() ещё раскручивает url'а на IP и content-type.

раскрашивают трейсбеки

Если не трейсбек, а кусок файла с ошибкой, как в tracy, то ошибка видна сразу и подсознание начинает искать вариант исправления всё то время, пока ты добираешься до нужного файла в редакторе. Это тоже заметно ускоряет цикл отладки.

tail -f

У меня нормальный отладочный выхлоп занимает заметно больше одного экрана. И сами логи могут быть вообще на разных машинах, немало взаимодействия в коде межнодового. И, вообще, с учётом удобства отладки обычно выгодно кидать не все ошибки в один файл, а каждую ошибку — в отдельный. Тогда, например, исправив одну типовую ошибку можно тупо grep/rm-нуть все такие ошибки в предыдущей истории и заняться следующими так, что ничего мешать не будет.

Ну что я могу сказать, мне так удобно, тебе по-другому. Спорить бесмысслено.

А ОПу посоветую самому решить, что удобнее именно для него.

Есть рабочий код:

<?php
$a='Hello';
echo $a;

?>

Но если в него добавить лишний символ, к примеру перед $a поставить 'a', то отображается пустая страница.

<?php
$a='Hello';
echo a $a;

?>

Вопрос, каким php отладчиками вы пользуетесь для поиска подобного рода ошибок?

PHP Parse error:  syntax error, unexpected '$a' (T_VARIABLE), expecting ',' or ';' in php shell code on line 1

Это должно где-то выскочить.

php codesniffer + flycheck/flymake

Отладчик тут не поможет, так как скрипт в случае синтаксических ошибок не запускается вообще. Смотри в мане PHP про error_reporting, display_errors и log_errors

+

добавлю еще debug_backtrace

а если уж очень хочется переопределяеш set_error_handler

обычно к этому все равно приходиш, но мож пользоватся выхлопом xdebug

error_reporting(E_ALL | E_STRICT);

error_reporting(-1);

Вот,да.