Начальная

Windows Commander

Far
WinNavigator
Frigate
Norton Commander
WinNC
Dos Navigator
Servant Salamander
Turbo Browser

Winamp, Skins, Plugins
Необходимые Утилиты
Текстовые редакторы
Юмор

File managers and best utilites

Пять инструментов отладки JavaScript, о которых полезно знать. Php отладка в браузере


Замолвим слово об отладке и профилировании [PHP] / Хабр

Все идет от лени. Вы получили чужой очень большой проект в котором нужно сделать небольшие правки, или же написали скрипт и сразу не очевидно, что в нем еще требует оптимизации. Как быть? Читать и анализировать код, выводить каждый шаг на экран или в файл (var_dump() и т.д.) не всегда эффективно, ведь можно воспользоваться средствами отладки, которых на сегодняшний день очень много. Кратко перечислю часто встречающиеся…Xdebug Debugger and Profiler Tool — расширение PHP. Требует установки на сервер и настройки. Может отображать: стек вызовов функций, распределение памяти. Возможности: профайлинг, анализ покрытия кода, защита от бесконечной рекурсии, интерактивная отладка скриптов. ПО для визуализации логов xdebug: Webgrind – веб-интерфейс для профайлинга Xdebug, написанный на PHP, MacGDBp – Mac OS X клиент, который позволяет отлаживать PHP приложения при помощи Xdebug. Linux GUI kcachegrind. Бесплатный. Интегрируется с многими IDE. См Profiling PHP Applications With xdebug. При включении опции в php.ini:html_errors = On будет форматировать вывод var_dump() и сообщения об ошибках.

Xhprof — расширение PHP от facebook. Требует установки на сервер и настройки. Позволяет собирать время выполнения каждой функции, использование памяти, время ожидания, количество вызовов и многое другое. Это расширение доступно из репозитория PECL. Почитать документацию можно тут [тыц]. Так же Профилирование и отладка php-приложений с помощью xhprof & FirePHP. Из преимуществ сильно не грузит систему, можно ставить на бой. Бесплатный.

DBG (PHP Debugger and Profiler) — расширение PHP. Требует установки на сервер и настройки. Позволяет работать на тестовом или/и рабочем сервере и отлаживать скрипты локально или удаленно, из IDE или консоли. Платная/бесплатная версии.

ZendDebug — расширение PHP, входит в состав Zend Studio (платная IDE). Требует установки на сервер и настройки. Позволяет практически все тоже, что и xdebug, GUI в IDE Zend Studio или Zend Server. Платный. Чуть ниже рассмотрим его более подробно.

Memtrack — расширение PHP. Позволяет искать утечки памяти. Удобно проверять скрипты запускаемые по крону или в качестве демона. Бесплатный. См. [тыц]

APD Advanced PHP debugger — расширение PHP. Слабый конкурент xdebug, но имеет в себе возможности memtrack. Плохо интегрируется с IDE, однако имеет консольный интерфейс (см. [тыц]). Бесплатный.

DTrace + PHP — расширение PHP. Низкоуровневая отладка. См. [тыц]. Так же не нужно забывать о существовании Strace и прочих системных отладчиков, которые порой способны показать где, так сказать, «собака порылась». Например strace -p 1111 анализ системных вызов скрипта, с PID=1111. Также сетевые анализаторы wireshark (Windows), ngrep, tcpdump (Linux) — для анализа сетевого трафика, протоколов и т.д.

FirePHP — класс, написан на php + расширение для FireFox. Дает возможность посылать отладочные сообщения в консоль Firebug с помощью вызова php методов. Вся информация посылается через заголовки X-FirePHP-Data, тем самым не пересекаясь с основным контентом страниц. Бесплатный. См. Отладка PHP средствами Firebug

php-console — написан на php + расширение для Google Chrome. Аналог FirePHP, только для Google Chrome, но несколько с другим функционалом. Бесплатный. См. php-console

PHP_Debug класс, написан на php. Помогает в отладке PHP кода, показывает путь выполнения скрипта, отображает все переменные, время выполнения, включенные файлы, выполненные запросы, watch переменные… Эта информация собирается во время выполнения скрипта, и отображается по его завершению и потом может быть использована в любой момент. Бесплатный.

Pinba — сервис мониторинга и статистики в реальном времени. См Мониторим php в реальном времени Мониторинг производительности PHP-кода с помощью Pinba. Бесплатная.

Статьи общего характера:Профилирование PHP-кодаОтладка сложных веб-приложений — эффективная багодробилка на production-серверах

Отладчики в современных CMS/CMF/Framework. Их не рассматриваем, т.к. зачастую они имеют специфику и разработаны под конкретную оболочку, что делает не возможным использование их извне (IDE) или применять без значительных изменений в своих разработках.

Для сбора и анализа узких мест в ваших приложениях иногда может пригодится методика централизованного хранении syslog, см [тыц].

Вернемся к ZendDebug. Так как я в основном пользуюсь Zend Studio, то мне наиболее удобно с ним работать. Он позволяет сразу понять ход выполнения скрипта, поддерживает навигацию по коду из IDE. Не нужны никакие сторонние инструменты, кроме IDE. Это действительно удобно, так сказать настроил один раз и пользуешься.

Отладка и профилирование скриптов в Zend Studio возможна как минимум двумя способами при помощи xdebug или ZendDebug. Только вот профилирование сайта с xdebug у меня не заработало, пишет что нельзя так — только отладка.

Про локальную отладку кода писали еще во времена Zend Studio 5.5 [тыц]. С тех времен мало что изменилось. Но я столкнулся с проблемой, когда web сервер и отлаживаемый код находится на удаленном сервере. Часто такие песочницы закрыты извне, а отрыты только нужные для работы порты. Но если к такой песочнице есть доступ по SSH, то настроить ZendDebug все таки можно, не мешая фаерволу выполнять свою функцию.

Забегая вперед отмечу, что для этого нужно будет создать SSH туннель. Немного о том, зачем SSH туннель нужен в этом случае.

По умолчанию Zend Studio инициирует сеанс удаленной отладки, отправив HTTP запрос на отладочный сервер. Этот запрос содержит параметры обратного адреса (IP-адрес и номер порта), который ZendDebug (установленный на сервере) использует при запуске нового подключения к Zend Studio, чтобы ретранслировать информацию об отладке. Кстати, инициализировать сам сеанс отладки можно как из IDE, так и из браузера установив компонент, поставляемый вместе с Zend Studio, будет довольно удобно.

Обычная отладочная сессия будет иметь место, например, в случае, когда код, WEB сервер и IDE находятся на локальном компьютере.

Но зачастую WEB сервер разделен с IDE брандмауэрами, маршрутизаторами, прокси-серверами т.д. Тут-то и пригодится SSH туннель.

В случае с туннелем процесс установления сеанса отладки состоит из двух основных этапов: — создания SSH туннеля; — настройки Zend Debugger, для передачи своего трафика через SSH туннель.

Схема отладочной сессии через SSH туннель примет вид: Обычная отладочная сессия через SSH туннель

Zend Studio, по умолчанию, открывает порт 10137. Его и будем использовать в примерах далее. Можно назначить и другой порт, если это необходимо.

Создание SSH туннеля в Linux или Mac OS X можно в командной строке: ssh <порт Zend Studio >:127.0.0.1:<порт для открытия debug server> @пример:

[email protected]:~> ssh -R 10137:127.0.0.1:10137 [email protected] [email protected]'s password: <enter user's password on the debug server> Welcome to the Debug Server! [email protected]:~$

Для создания SSH туннеля в Microsoft Windows, можно использовать PuTTY. После создания рабочего SSH соединения, необходимо дополнительно настроить туннель.

Со стороны IDE проверьте, что слушаются порт 10137 и локальный IP адрес 127.0.0.1

Практика тенулирования трафика вам может пригодится и для других целей. Например локальными утилитами делать SQL-дампы СУБД, когда удаленная база разрешает соединение только с 127.0.0.1 и т.д.

Думаю из списка выше каждый сможет найти себе удобный инструмент на каждый день. И что бы разработка приносила еще больше удовольствия, а на вопрос — «Что случилось? Почему лежим?», был всегда оперативный ответ.

Приятной отладки и скриптов без ошибок, спасибо за внимание.

udp. добавил php-console, спасибо Arik

habr.com

Debugging PHP applications with xdebug / Хабр

Добро пожаловать на 4 часть повествования о xdebug. Сегодня мы попытаемся разобраться в отладке PHP кода с помощью xdebug. В данной статье мы полагаем, что вы уже давно установили xdebug на вашу систему, если нет первая статья серии опишет вам как это сделать.

Отладка программного обеспечения самая ненавистная работа доля разработчика. Большинство используют для отладки связку echo(print_r,var_dump) и exit(die), переходя от одной строке к другой. Однако, если ошибка появляется вновь в этом файле, требуется заново прописывать отладочные команды. Можно конечно отладку обернуть внутри конструкции if, которая будет работать только, когда определена какая-либо константа, например DEBUG. Но каждый такой if будет слегка замедлять производительность, да и смотреться будет в коде очень ужасно. Как мы уже изучили во второй части нашего повествования, наличие xdebug позволяет нам создавать логи трассировки, достаточно хороший выход для данной ситуации, вам не надо будет изменять программу. Однако лог трассировки, особенно когда он создан для части программы, предоставляет нам много информации, не имеющей никакого отношения к отладке, таким образом, использование отладчика это оптимальное решение. Отладчик позволит вам остановить запуск программы на некоторое время, проверить или модифицировать текущее значение переменной, а затем продолжить выполнение программы. Запуская программу шаг за шагом, вы можете близко взглянуть как выполняется ваш код, что поможет найти вам места ошибок. До появления функции var_dump, отладка приложений в PHP была проблематичной, если у вас не было денег для покупки коммерческого IDE, который поддерживал отладку. С выходом xdebug проблема отладки приложений теоретически была решена. Я написал теоретически потому что не существует хорошего и бесплатного клиента для отладки как для Windows, так и для Unix. Однако и эта проблема была решена с выходом Eclipse PDT. Eclipse PDT это бесплатный IDE для PHP поддерживающий xdebug. Поэтому давайте, не торопясь, рассмотрим установку Eclipse PDT для того чтобы начать отладку.

Установка Eclipse PDT

Eclipse PDT (PDT это аббревиатура от PHP Development Tools) написан на Java, и поэтому будет работать на большинстве платформ, где установлен Java Runtime Environment. Если у вас его нет, то можете скачать с www.sun.com. Вы можете скачать готовую версию Eclipse PDT с www.eclipse.org/pdt. Вы можете выбрать подходящую версию для вашей операционной системы. Когда была написана эта статья, версия Eclipse PDT была R20070917. Выберете последнюю версию, нажмите скачать и сходите куда-нибудь покушать, так как размер Eclipse PDT около 100 MB. После скачивания, распакуйте файлы и можно приступать к работе.

Как работает отладка

До того как мы погрузимся в конфигурирование xdebug и Eclipse PDT, давайте рассмотрим как работает отладка в PHP с использованием xdebug. Это поможет вам лучше понять те параметры конфигурации, которые мы будем обсуждать позже. Когда отладка включена в php.ini, xdebug начинает контролировать выполнение программы, это значит, что xdebug может останавливать выполнение программы в любой момент, а потом запускать ее с точки останова. Когда выполнение программы остановлено, xdebug может получить информацию о текущем состоянии программы, например прочитать текущие значения переменных. Также xdebug представляет возможность изменять значения переменных во время выполнения скрипта. Расширение xdebug – это сервер, ожидающие соединений с клиентами на определенном порту, задаваемом в конфигурации. Существует два протокола, которые могут быть использованы для коммуникации между xdebug-клиентом и xdebug-сервером (GDB и DBGp). GDB – это старый протокол, который был заменен на DBGp. Посылая команды серверу-xdebug, xdebug-клиент удаленно контролирует выполнение, сообщает PHP о приостановке запуска, выполнении следующей строчки кода или продолжении выполнения программы. Клиент обычно встроен в редактор или IDE (в нашем случае в Eclipse PDT), поэтому вы не будете иметь дело с протоколом общения напрямую. Веб-сервер с xdebug может быть запущен на другой операционной системе, нежели xdebug-клиент. Вот почему xdebug называется удаленным отладчиком(remote debugger). Для упрощения, мы настроим сервер и клиент на одном и том же компьютере. Существует два режима начала сессии отладки. Эти режимы контролируются в php.ini настройкой xdebug.remote_mode. Значение по умолчанию req, xdebug-клиент будет соединятся с сервером всякий раз когда начинается выполнение скрипта. Если вы хотите, чтобы xdebug соединялся с сервером только тогда, когда установлен breakpoint или когда в скрипте возникла ошибка, вы можете установить xdebug.remote_mode в jit. Я рекомендую оставить значение по умолчанию, это избавит вас от модификации php.ini . Для того чтобы начать отладку, вы должны послать параметр XDEBUG_SESSION_START в скрипт как часть GET, POST или COOKIE. Значение этого параметра это название сессии отладки, которое должно быть уникальным, по имени сессии xdebug может различать различные сессии, запущенные параллельно. Для завершения сессии отладки необходимо послать скрипту команду XDEBUG_SESSION_STOP. Вместо того чтобы вручную начинать и заканчивать отладочные сессии, вы можете установить специальный firefox plugin, который поможет вам легко начинать и заканчивать сессии одним нажатием мышки. Используя Eclipse PDT, вам не придется беспокоится по поводу плагина для браузера, так как IDE берет на себя отправку необходимых параметров.

Настройка xdebug

Сейчас давайте приступим к настройки отладки. Добавьте следующие настройки в php.ini:

xdebug.remote_enable=On xdebug.remote_host=«localhost» xdebug.remote_port=9000 xdebug.remote_handler=«dbgp» Проверьте, чтобы эти строки были добавлены после строки zend_extension_ts, которая загружает xdebug. Первая строка включает режим отладки. Вторая строка определяет, что клиент отладки запущен на локальном компьютере, в случае если клиент и сервер на разных компьютерах необходимо поставить название сервера или IP- адрес. Третья строка указывает порт, на котором отладочный клиент будет ожидать ответа от сервера. По умолчанию значение 9000. На это значение Eclipse настроен по умолчанию. Если вы собираетесь изменить это значение, не забудьте поменять это в настройках Eclipse и php.ini. Итак, убедитесь, что файервола не будет препятствием для осуществления отладки. При старте Eclipse, вы можете видеть сообщения, что Java пытается запустить сервер, забиндиться на порт, получить доступ к сети или выполнить какую-либо страшную операцию. Конечно, это не опасно, xdebug пытается слушать 9000 порт. Если у вас возникают какие-либо проблемы, проверьте, не блокирует ли что-то 9000 порт между клиентом и сервером. В последней строке, мы говорим, какой протокол будет использовать клиент. Eclipse PDT использует DBGp.

Настройка Eclipse PDT

Создайте новый PHP проект в Eclipse PDT. Пусть он называется debug_test. Создайте файл debug.php в проекте, добавьте немного кода и сохраните файл. Сейчас давайте настроим Eclipse для отладки. Во-первых, мы настроим Eclipse для запуска проектов во внешнем браузере в замен внутреннего. Когда это будет настроено, все сессии отладки будут запущены во внешнем браузере. Использование внешнего браузера не является обязательным, однако я предпочитаю работать в Firefox вместо внутреннего браузера Eclipse. Выберите Window в меню, затем Preferences (см. скриншот внизу). Откройте поддерево General, и выберите Web Browser. Теперь отметьте Use external browser и нажмите Apply.

Eclipse PDT поддерживает как Zend debugger так и xdebug. По умолчанию выбран Zend debugger. Для изменения откройте поддерево PHP, затем поддерево Debug. Затем измените PHP debugger на Xdebug и нажмите Apply. Теперь, выберите Run в меню и выберите Open Debug Dialog. Затем, дважды кликните на PHP Web Page для создания новой конфигурации отладки. Вы будите видеть три вкладки: Server, Advanced и Common. Выберите Xdebug как Server Debugger. В поле File / Project вы должны выбрать путь к скрипту, котрый вы хотите отладить. Путь должен быть относительный к текущему workspace. В моей системе это /debug_test/debug.php. Нажмите Browse и выберите debug.php в каталоге debug_test. Eclipse необходимо знать URL, соответствующий исходному скрипту и пути, по которому вы его вызываете. Это требуется для подсветки текущей выполняемой строки в исходном коде. Текстовое поле URL показывает URL, соответствующий названию скрипта. По умолчанию поле URL неактивно, так как активен флажок Auto Generate. Если указываемый URL не соответствует URL, который вы ввели в File / Project, снимите Auto Generate и введите правильный URL в текстовое поле URL. Если данный скрипт требует GET-параметров, вы можете ввести их в данное поле. Не забывайте нажимать Apply для сохранения изменений. Следующий скриншот показывает как конфигурация выглядит на моей системе:

Выберите вкладку Advanced и проверьте, выбраны ли Open in Browser и Debug All Pages. Теперь можно закрыть окно настроек и начать отладку.

Отладка PHP скрипта

Для начала отладки PHP-скрипта, выберите Run-> Debug (или нажмите F11). Eclipse спросит вас, где вы хотите видеть отладочную информацию. Следующий скриншот показывает окно отладки Eclipse моего debug.php:

Eclipse открывает браузер. Вы не сможете ничего увидеть, потому что Eclipse по умолчанию останавливает выполнение скрипта на первой строке, как будто бы на этой строке была установлена точка останова. Если вы хотите отключить такое поведение, снимите флажок Break at First Line в секции Breakpoint в диалоге отладки в окне настроек. Как показано на скриншоте, вы видите исходный код отлаживаемого файла, текущая строка выполняемой программы отмечена стрелочкой. В верхней правой области вы можете выбрать несколько вкладок. Вкладка Variables показывает значения всех переменных в данной области видимости. Суперглобальные переменные валидны во всех областях видимости, пойэтому они всегда будут отображаться. Вкладка Breakpoints позволяет видеть и редактировать все точки останова в вашем скрипте. Eclipse запомнит все точки останова из вашего кода, всякий раз когда вы закрываете и перестартуете Eclipse. Вы можете продолжить выполнение программы до следующей точки останова, выполнить одну строчку кода, войти в следующую функцию или выйти из функции кликнув на соответствующую кнопку Debug в левой верхней области. Пошаговый проход очень полезен, когда вы пытаетесь локализовать место ошибки в вашем коде. Вы можете видеть как меняются значения переменных на каждом шаге.

Изменение переменных во время выполнения

Вы также можете изменять значения переменных во время выполнения. Для изменения переменной, кликните на текущее значение, измените его и нажмите Enter.

Точки останова

Точка останова приостанавливает выполнение программы и позволяет вам подробно рассмотреть состояние переменных, затем продолжить выполнение программы. Выполнение программы также останавливается, когда в программе выпадает исключение. Для установки точки останова, нажмите правую кнопку мыши на строке, затем выберите Toggle Breakpoints в контекстном меню. Вы можете удалить точку остановатаким же образом или удалить во вкладке Breakpoints. Вы также можете добавить точки останова по условию (conditional breakpoint). Такие точки останова будут приостанавливать выполнение программы только тогда, когда выполнится условие. Это может быть очень полезно, когда некоторый кусочек кода выполняется много раз с различными параметрами на входе. Для добавления подобной точки останова, нажмите правую кнопку мышки на изображении точки останова, выберите Breakpoint Properties. Проверьте флаг Enable Set Condition и введите условие в текстовое поле. в моем debug.php функция test() вызывается в строке 11, и точка останова установлена в этой строке. Если мы добавим условие $a!= '' xdebug остановит выполнение программы в этой строке только когда локальная переменная a будет не пуста. Для окончания отладки, нажмите кнопку Terminate на панели Remote Launch. Если Eclipse запускает скрипт в внешнем браузера, просто закройте его окно.

Заключение

Удаленная отладка – это интерактивный и ненавязчивый путь поиска ошибок в ваших программах. Вместо вставки вызовов var_dump() в код или анализа лога трассировки на предмет отслеживания значений переменных, отладка предоставляет вам вид «под микроскопом» каждого участка вашей программы. Следующая статья будет посвящена созданию объемлющей статистики, используя xdebug.

habr.com

Отладка исходного PHP кода в NetBeans IDE

Отладка исходного PHP кода в NetBeans

Отладка исходного PHP кода в NetBeansВ этой статье я расскажу про отладку исходного php кода в NetBeans IDE. Отладка (или трассировка) исходного кода — это очень полезная и в некоторых случаях просто незаменимая вещь. Когда ты создаешь свой модуль, пишешь свой php движок, или разбираешься в чужих модулях или программах, зачастую, чтобы найти ошибку в исходного коде, без отладки бывает просто не обойтись.

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

Перед тем, как начать отладку исходного кода в NetBeans, нужно  установить и настроить Xdebug на локальном сервере.

После установки Xdebug можно настроить среду программирования NetBeans IDE.

Первое, с чего нужно начать — это с настроек проекта в NetBeans. Щелкните по названию проекта в браузере проектов правой кнопкой мыши и откройте его свойства. В открывшемся окне, слева, в списке категорий выберите пункт «выполнить настройку»:

Настройка отладки php кода в NetBeans

Настройка отладки php кода в NetBeans

В поле «URL-адрес проекта» наберите адрес вашего проекта на локальном сервере. В этой статье рассматривается отладка PHP скриптов, размещенных на локальном сервере. В поле «Файл индекса» выберите файл, с которого вы бы хотели начать отладку проекта. В PHP движках это обычно index.php. Далее, слева в списке выберите пункт «Браузер». Выберите браузер, в котором вы будете отлаживать ваш PHP проект. Я обычно оставляю в этом поле браузер по умолчанию. Нажмите «ОК».

Зайдите в меню сервис->параметры, перейдите к пункту PHP и выберите вкладку «Отладка»:

Настройка отладки в NetBeans

Настройка отладки в NetBeans

Поставьте галочку у пункта «Наблюдения и оценка во всплывающем окне». В последствии вы можете убрать галку у пункта «Остановиться в первой строке», так как часто она мешает, особенно при отладке больших проектов.

Все, теперь можно запускать отладку PHP скриптов, нажмите «Отладка проекта» на панели инструментов, или нажмите комбинацию клавиш Ctrl+F5.

Отладка PHP кода в NetBeans

Отладка PHP кода в NetBeans

После этого в среде программирования откроется отлаживаемый файл скрипта. Если вы не убрали галочку «Остановиться в первой строке», выполнение отлаживаемого скрипта остановится на первой строке и она будет подсвечена зеленым цветом.

После остановки скрипта вы можете выполнять его далее, пошагово, нажимая клавиши F7 или F8.

При остановке скрипта, вы можете наблюдать значения переменных в окне «Переменные» (см. скриншот выше). Кроме окна «Переменные» в режиме отладки есть окно «Стек вызовов» и «Точки останова».

При отладке вы можете смотреть содержимое переменных или вычислять выражения. При остановке скрипта в определенной точке выполнения выделите нужную переменную или участок кода и наведите на него мышкой, вы увидите значение этой переменной, или выражения (если оно к этому времени уже определено). Так же вы можете добавлять желаемые переменные или выражения в окно «Переменные» для дальнейшего просмотра их результата. Для этого выделите нужный участок кода, или переменную, нажмите на ней правой кнопкой мыши и в появившемся контекстном меню выберите «Создать наблюдение», либо нажмите Ctrl+shift+f7. После эта переменная (или выражение) появится в окне «Переменные» и по ходу отладки можно будет смотреть как изменяется ее значение.

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

Отладка исходного PHP кода в Netbeans. Точки останова

Отладка исходного PHP кода в Netbeans. Точки останова

Поставив точку останова, запустите скрипт или продолжите отладку, нажав Ctrl-F5 для запуска или F5 для продолжения выполнения скрипта. Скрипт должен остановиться на созданной вами точке останова. После остановки скрипта вы можете выполнять его пошагово, нажимая клавиши F7 или F8.

Часто отлаживаемый код бывает слишком большим и выполнять его пошагово, включая все циклы и условия, слишком муторно и долго. Чтобы этого избежать, можно «прыгать» от одного участка кода к другому, избегая те участки кода, отладка которых вам не нужна. Для этого нам пригодятся несколько точек останова. Например у вас в скрипте есть цикл, выполнять пошагово который придется долго, вам нужно пропустить этот участок кода с циклом и продолжить отладку дальше. Для этого нужно поставить одну точку останова перед циклом, а другую на участке кода ниже этого цикла. При остановке скрипта на первой точке останова нажмите «Продолжить» (зеленый кружок на панели отладки), либо F5, тогда скрипт продолжит свою работу, перепрыгнув участок кода между двумя точками останова, то есть выполнит цикл, и опять прервет свою работу на второй точке останова, которая была установлена после цикла. Таким способом можно эффективно отлаживать код скрипта, пропуская ненужные участки кода и останавливать выполнение скрипта в нужных местах. Вы можете поставить несколько точек останова в разных частях одного скрипта.

Что делать, если отладка PHP кода в NetBeans не работает?

Если у вас не ловятся точки останова, еще раз убедитесь, что xdebug правильно установлен и настроен.

Далее зайдите в сервис->параметры->PHP->отладка, поставьте галочку у пункта «Останавливаться в первой строке». Запустите отладку. Если выполнение скрипта не остановилось на первой строке и в нижней части программы отображается надпись «ожидание подключение xdebug», то возможная причина может быть в том, что порт xdebug (по умолчанию 9000) занят какой то другой программой. Убедитесь в том, что 9000 порт не занят другой программой, или измените порт xdebug по умолчанию в настройках php.ini и укажите его в настройках NetBeans:

Отладка исходного PHP кода в Netbeans. Настройка отладчика Xdebug

Отладка исходного PHP кода в Netbeans. Настройка отладчика Xdebug

Убедитесь в том, что ваш локальный веб-сервер правильно настроен и включен.

webistore.ru

Отладка PHP приложений на удаленном хосте при помощи XDebug и vim в Linux / Хабр

Введение
В PHP приложениях отладка при помощи var_dump, debug_backtrace и прочих полезных функций не всегда удобна, и возникает потребность в полноценном отладчике. Эта статья — для тех, кто по каким-либо причинам не хочет использовать IDE, поддерживающие отладку PHP приложений из коробки, вроде NetBeans или PhpStorm, а хочет использовать для этих целей vim, и при этом отладка происходит на удаленном хосте. Для vim существует плагин «DBGp client», но он позволяет нормально отлаживать только в случае, когда пути до всех файлов на удаленной и на локальной машинах одинаковые. Например, если локальной машине у вас есть:/home/user/application/ /home/user/framework/ а на удаленной машине они расположены в:/var/www/html/application/ /var/www/framework/ то отладить приложение при помощи «DBGp client» не получится, так как он ничего не знает о другом расположении исходников.

В данной статье мы рассмотрим:

  1. Кратко — настройку всего необходимого для удаленной отладки приложения.
  2. Модификацию плагина для поддержки различных путей.
  3. Кратко — использование отладчика.
Установка
Настраиваем vim на локальном хосте
Скачайте и установите плагин:$ cd ~/.vim $ wget www.vim.org/scripts/download_script.php?src_id=7285 -O debugger.zip $ unzip debugger.zip $ rm debugger.zip

Внимание: vim должен быть собран с поддержкой python, проверить это можно при помощи ":version", в выводе должна быть строка "+python".

Устанавливаем и настраиваем Xdebug на удаленном хосте
Установите расширение Xdebug любым удобным для вас способом. Например, на Debian Squeeze это делается просто:# apt-get install php5-xdebug А в общем случае, лучше почитать официальную инструкцию по установке.

Настройте подключение к локальному debug-клиенту — для этого в php.ini пропишите следующие строчки, заменив 192.168.1.110 на IP локальной машины (при необходимости порт тоже можно перенастроить):xdebug.remote_enable = 1 xdebug.remote_port = 9000 xdebug.remote_host = 192.168.1.110

Настраиваем соответствие файлов
Идея простая — при отправке запроса дебагеру (например, на установку breakpoint), мы должны преобразовывать путь на локальном хосте в путь на удаленном хосте, и наоборот, при получении информации от дебагера (например, о том что сейчас он находится на какой-то строке какого-то файла), мы должны сделать обратное преобразование. Дописываем в конец файла debugger.py следующий код:class FileMapping: def __init__(self, mapping_file): self.local_to_remote = {} self.remote_to_local = {} mapping = open(mapping_file, 'r') for line in mapping: local, remote = line.split(' ') local = local.strip() remote = remote.strip() if not (local in self.local_to_remote): self.local_to_remote[local] = [] self.local_to_remote[local].append(remote) if not (remote in self.remote_to_local): self.remote_to_local[remote] = [] self.remote_to_local[remote].append(local) def local_to_remote_file(self, local): for local_path in self.local_to_remote.keys(): if local.startswith(local_path): # use the first mapping as we don't know which one we should take remote_path = self.local_to_remote[local_path][0] return remote_path + local[len(local_path):] def remote_to_local_file(self, remote): for remote_path in self.remote_to_local.keys(): if remote.startswith(remote_path): for local_path in self.remote_to_local[remote_path]: local = local_path + remote[len(remote_path):] # use the first existing file if os.path.exists(local): return local return None file_mapping = FileMapping('/home/alexey/mapping')

А в файл mapping (/home/alexey/mapping — замените на свой путь) записываем соответствие локальный и удаленных директорий, например:/home/alexey/framework /var/www/framework /home/alexey/application /var/www/html

Просматриваем код плагина в поисках мест, где от Xdebug приходят имена файла. В итоге, все они сводятся к вызову одного метода — set_srcview, в начало которого мы и добавляем изменение имени файла:

def set_srcview(self, file, line): """ set srcview windows to file:line and replace current sign """ file = file_mapping.remote_to_local_file(file) Теперь ищем места, где наоборот от debug-клиента к Xdebug передаются имена файлов. Таких мест два: 1. Класс Debugger, метод run, заменяем строку'-t line -f ' + self.breakpt.getfile(bno) + ' -n ' + str(self.breakpt.getline(bno)) + ' -s enabled', \ на'-t line -f ' + file_mapping.local_to_remote_file(self.breakpt.getfile(bno)) + ' -n ' + str(self.breakpt.getline(bno)) + ' -s enabled', \ 2. Класс Debugger, метод mark, заменяем строку:'-t line -f ' + self.breakpt.getfile(bno) + ' -n ' + str(self.breakpt.getline(bno)), \ на'-t line -f ' + file_mapping.local_to_remote_file(self.breakpt.getfile(bno)) + ' -n ' + str(self.breakpt.getline(bno)), \

Уже поправленный debugger.py можно взять тут.

Использование
Запускаем отладку
Чтобы начать отладку web-приложения, необходимо запустить vim и нажать . Далее, в течение 5 секунд (ниже описано, как увеличить интервал), необходимо запустить какой-либо PHP скрипт, передав GET-ом переменную XDEBUG_SESSION_START со значением 1, например просто открыв соответствующую страницу в браузере, например:webdev/debug.php?XDEBUG_SESSION_START=1 Альтернативно в php.ini можно задать переменную xdebug.remote_autostart. В таком случае, при запуске любого PHP скрипта, Xdebug будет пытаться подключиться к debug-клиенту. Подробнее можно прочитать в официальной документации Xdebug. В итоге должно получиться что-то вроде этого — должен открыться скрипт, который вы запустили:

Окна справа — сверху вниз:

  1. WATCH WINDOW — просмотр контекста
  2. HELP WINDOW — краткое описание возможностей
  3. STACK WINDOW — стек вызова функций
  4. TRACE WINDOW — лог общения debug-клиента c Xdebug, полезно посмотреть если отладка не заработала
Настройка под себя
Таймаут можно задать в том же скрипте, найдя в debugger.py строку:serv.listen(5) и заменив 5 на нужное вам количество секунд. Комбинации клавиш задаются в debugger.vim, например себе я переназначил на нажатие «,dr»:map ,dr :python debugger_run()<cr> Текст в HELP WINDOW можно поменять в классе HelpWindow, методе on_create.
Навигация по коду
Подробно расписывать не буду, отличия от других отладчиков тут минимальные:
  • Step into (<F2>) — шаг с заходом внутрь функций.
  • Step over (<F3>) — шаг без захода внутрь функций.
  • Step out (<F4>) — выход из функции по стеку вверх.
  • Run (<F5>) — продолжить выполнение до следующего breakpoint.
  • Stack up (:Up) — переход по стеку вверх (смотрите STACK WINDOW).
  • Stack down (:Dn) — переход по стеку вниз (смотрите STACK WINDOW).
Просмотр текущего состояния
  • Property get (<F12>) — получить значение переменной (надо поставить курсор на нужную переменную и нажать <F12>).
  • Context get (<F11>) — получить весь текущий контекст (грубо говоря, все переменные, доступные в данном контексте).
  • Eval (,e) — выполнить произвольное выражение в текущем контексте и получить его значение.
На скриншоте — WATCH WINDOW с выполнеными Context get и Eval:

Установка breakpoints
Toggle breakpoint (:Bp) — установить breakpoint в текущей строке, или удалить, если он уже есть. На скриншоте — зеленая строка — это строка с breakpoint, красная — это текущая строка:

Resize
Дополнительно по можно переключатся между двумя режимами — полный, когда показываются различные вспомогательные окна справа, и простым — когда остается только окно с кодом.

habr.com

Отладка PHP в NwetBeans-xdebug

Вопрос: [php + xdebug] Необычная конфигурация и... какой-то парадокс

Для отладки сайта подготовил такую конфигурацию.1.Сервер разработки (Linux + nginx + php-fpm + xdebug) развёрнут на гостевой машине (с помощью Virtual Box)2.Все файлы сайта физически хранятся на хост-машине (Windows 10), а в гостевой машине директория сайта mount'ится (используется функционал Virtual Box по созданию общих папок)3.PHPStorm установлен также на хост-машине, отладка кода выполняется на хост-машине4.Средствами Virtual Box с помощью NAT-сети настроен проброс порта со 127.0.0.1:80 хост-машины на 10.0.2.15:80 гостевой машины (10.0.2.15 - это IP гостевой машины в NAT-сети), плюс файл host, чтобы при запросе страниц сайта из хост-машины запросы физически поступали в гостевую машину (на сервер разработки). Запросы нормально работают.

Задача заключается в настройке связки PHPStorm + xdebug. PHPStorm работает на хост-машине, xdebug - в гостевой машине. Нужно их подружить. В PHPStorm указал порт отладки 9999, тот же порт указал в настройках xdebug. также в настройках xdebug прописан [xdebug.remote_connect_back = 1], чтобы xdebug определял ip-адрес клиента отладки (в данном случае клиентом отладки является PHPStorm, работающий на хост-машине) автоматически из полученного запроса.

Что имеем (ситуация 1)Если средствами Virtual Box добавить проброс порта с 127.0.0.1:9999 хост-машины на 10.0.2.15:9999 гостевой машины (10.0.2.15 - это IP гостевой машины), то при попытке включения прослушки PHPStorm ругается: "Can't start listening for connections from 'xdebug': Port 9999 is busy". Понятно, почему - порт 9999 слушает Virtual Box (чтобы пробрасывать все запросы с этого порта в гостевую машину).

Что имеем (ситуация 2)Убираем проброс порта с 127.0.0.1:9999 хост-машины на 10.0.2.15:9999 гостевой машины. После этого прослушка в PHPStorm включается нормально. Ставим breakpoint и отправляем запрос веб-серверу с параметром XDEBUG_SESSION_START (не важно как - из самого PHPStorm или из браузера с установленным и включенным xdebug-плагином).

В итоге на хост-машине имеем:1) баузер ждёт ответа2) PHPStorm активирует кнопку "Stop" (красный квадрат) - отсюда делаем вывод, что PHPStorm получил на порт 9999 команду инициализации от xdebug (иначе запрос был бы сразу завершён как при обычном запуске НЕ в режиме отладки)3) До breakpoint дело не доходит, PHPStorm бесконечно ждёт, браузер тоже ждёт4) Если в PHPStorm нажать кнопку "Stop" (красный квадрат), то запрос завершается, в браузере отображается HTML-код запрошенной страницы (как при запуске обычного запроса НЕ в режиме отладки) - отсюда делаем вывод, что PHPStorm нормально отправляет xdebug'у (работающему на гостевой машине) запрос на завершение отладки, а xdebug нормально получает этот запрос и отправляет хост-машине HTML-код запрошенной страницы

Эти два вывода подтверждаются логами xdebug. После начала сессии отладки:

автор
Log opened at 2017-07-07 19:14:10I: Checking remote connect back address.I: Remote address found, connecting to 10.0.2.2:9999.I: Connected to client. :-)-> <init xmlns="urn:debugger_protocol_v1" xmlns:xdebug=" fileuri="file:///home/user/www/site/index.php" language="PHP" protocol_version="1.0" appid="981" idekey="12155"><engine version="2.2.5"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick Rethans]]></author><url><![CDATA[[CDATA[Copyright (c) 2002-2014 by Derick Rethans]]></copyright></init>

<- feature_set -i 1 -n show_hidden -v 1-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug=" command="feature_set" transaction_id="1" feature="show_hidden" success="1"></response>...

При завершении сессии отладки (жмём кнопку "Stop" в PHPStorm):автор
<- stop -i 19-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug=" command="stop" transaction_id="19" status="stopped" reason="ok"></response>

-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug=" command="stop" transaction_id="19" status="stopping" reason="ok"></response>

<- run -i 20Log closed at 2017-07-07 19:17:33

Как видно из логов, коннект между PHPStorm и xdebug состоялся успешно.Но тогда почему PHPStorm не получает от xdebug (ждёт бесконечно) состояние в точках останова ?

Это можно объяснить тем, что после инициализации сессии отладки PHPStorm не получает ничего на порт 9999. Поэтому и ждёт бесконечно. Но тогда каким образом выполняется успешный коннект между PHPStorm и xdebug (если PHPStorm ничего не получает на порт 9999), о чём прямо написано в логах xdebug ? Парадокс...

forundex.ru

Отладка Javascript в различных браузерах и средах / Хабр

Все мы прекрасно знаем как отлаживать JavaScript в FireFox — конечно же это FireBug. Какие же аналоги существуют в других браузерах…
FireFox — Firebug
Последняя версия: 1.3 / 1.4 alpha (что нового)Официальный сайт: http://getfirebug.com/Возможности: * Расширяемый (FireCookie, FirePHP и т.д.) * Удобный просмотр исходного кода страницы. Функция Inspect позволяет точно определить местонахождение тега того или иного элемента, просмотреть все «привязанные» к нему свойства и стили. * Редактирование HTML и CSS прямо в браузере. Можно изменять атрибуты тегов и значения свойств для того, чтобы пронаблюдать изменения. Удобно для тех случаев, когда нужно путём экспериментов найти наиболее приемлемый вариант оформления создаваемой страницы. * Отладка JavaScript. * Отслеживание процесса загрузки страницы. * Просмотр HTTP-заголовков обычных и AJAX-запросов.Скриншот:
Opera — Dragonfly
Последняя версия: alpha 3Официальный сайт: http://www.opera.com/dragonfly/Возможности: * Просмотр DOM; * Просмотр и редактирование CSS; * Отладчик JavaScript; * Просмотр HTTP и HXR запросов; * Отлаживать страницы для мобильных устройств; * Удалённо подключаться к любым компьютерам и устройствам с установленным браузером Opera, поддерживающим данный инструмент, и осуществлять отладку веб-страниц. * Консоль ошибок; * Командная строка.О расширении: Для того, чтобы появилась внизу панель DragonFly вам необходимо выбрать в главном меню Оперы пункт Tools -> Advanced ->Developer Tools. Там будет вкладка Error Console, а в ней вкладка JavaScript. Это и есть консоль ошибок. Сюда же мы можем выводить и отладочную информацию из скрипта. Но, увы, объекта console нет. Однако есть opera.postError() — аналог console.log().Скриншот:
IE — Companion.JS
Последняя версия: 0.4.2Официальный сайт: http://www.my-debugbar.com/wiki/CompanionJS/HomePageВозможности: * Детальная информация о JS-ошибке (реальное имя файла, строка и вызовы функций до ошибки) * FireBug-подобная API для консоли * Консоль позволяет исследовать объекты * Иконка на панели инструментов для вызова панели Companion.JSСкриншот:Статьи на хабре: JavaScript debugger для IE
IE — Microsoft Script Editor
Последняя версия: ставиться вместе с Office 2003MSDN: http://msdn.microsoft.com/en-us/library/aa189846(office.10).aspxВозможности: * Использовать Visual Studio для отладки.Подробнее: Отладка для Internet Explorer (в Visual Studio) Спасибо alemiks
IE — WebDeveloper V2
Последняя версия: 2.4.1 (3/12/2008)Официальный сайт: http://www.ieinspector.com/dominspector/Возможности: * Веб-инспектор — возможность просматривать DOM-модель страницы и ее динамическое изменение, стили и т.д. * Есть консоль как в Firebug * Писать логи из JavaScript * HTTP-монитор — позволяет просматривать отправляемые и получаемые запросы со страницыМинус: программа платная :( Скриншот: Спасибо megahertz
IE8 — встроеный
в IE8 встроен developer tool, в котором есть отладчик и профайлер jsОб отладчике: Однако, как пишут в интернете, он не очень хорош — нет console, ничего нельзя сделать пока не нажмешь остановить отладку, нельзя изменить DOM и стили на лету и т.д. Спасибо XaocCPS
Safari (любое WebKit-приложение) — Drosera
Последняя версия: выпускают каждую ночь новый билдОфициальный сайт: https://trac.webkit.org/wiki/DroseraВозможности: * Установка breakpoint * Есть объект console * Функциональный стэкСкриншот:Статьи на хабре: Не большое упоминание Safari для веб-разработчиков
Любой браузер — Firebug Lite
Последняя версия: 1.2.1Официальный сайт: http://getfirebug.com/lite.htmlВозможности: * Поддерживает все основные команды FireBugСкриншот:Статьи на хабре: Firebug lite

Подробнее можно почитать Отладка JavaScript в Opera, FireFox, IE и Safari

P.S. Знаете что-то еще, пишите в комментариях — с удовольствием допишу.

UPD: * Перенес в JavaScript * Добавлен IE+WebDeveloper V2 * Добавлен IE+Microsoft Script Editor * Добавлен IE8

habr.com

Пять инструментов отладки JavaScript, о которых полезно знать

Вы смотрите на код и не можете понять — почему! Почему он делает нечто неожиданное, и в общем-то, если не близится дедлайн, интересное. Однако от всех этих неожиданностей, в любом случае, надо избавляться.

Прежде чем вы, бросив всё остальное, кинетесь складывать в кучу найденные где-то строчки программ, которые, вроде бы, способны решить вашу задачу, ответьте пожалуйста на три вопроса:

  1. Выполнение каких действий вы ожидаете от своей программы?
  2. Почему вы ожидаете этого от программы?
  3. Делает ли программа то, что вы от неё ожидаете?
Если вы не можете ответить на первых два вопроса — желаю удачи в копипасте, но, если вы знаете — что вы ожидаете от кода и почему — существуют инструменты, которые способны помочь вам понять, делает ли код то, чего от него ждут. После того, как вы убедитесь в том, что ваши ожидания относительно некоего фрагмента программы оправдались, либо вы смогли исправить ошибку — переходите к следующему фрагменту и проверяйте его. Вот несколько полезных инструментов, которые помогут вам вывести ошибки на чистую воду.

Проверка значений переменных

Начнём, вне основного списка отладочных средств, с самого простого и очевидного. Команда console.log() может оказаться весьма полезной для проверки таких вещей, как переменные, объявленные с помощью var и let, константы, объявленные с использованием const, объекты arguments и this. В момент вывода значения эти данные актуальны, но знайте о том, что иногда консоль Chrome выводит данные, обновлённые после выполнения программы. С осторожностью относитесь к данным, после которых идёт светло-синий значок с белой буквой «i».

Работа в браузере: с осторожностью относитесь к выведенным данным, после которых находится светло-синий значок с белой буквой «i». Возможно, эти данные были обновлены после выполнения программы

№1: инструменты разработчика Chrome — отладчик

Более надёжной альтернативой использования console.log() является отладчик Chrome. Для того, чтобы им воспользоваться, добавьте команду debugger в ту строку вашего кода, в которой вам хотелось бы исследовать значения переменных. Сохраните файл, затем откройте панель инструментов разработчика Chrome, например, следующими командами:iOS: Cmd + Opt + I Windows: Ctrl + Shift + I Перейдите к странице, код которой исследуете, скажем, это может быть что-то вроде localhost:PORT_NUMBER или адрес страницы на разрабатываемом сайте, либо, если страница уже открыта, перезагрузите её. Исполнение приостановится на команде debugger и вы сможете исследовать программу.

Работа в браузере: исполнение приостановится на команде debugger и вы сможете исследовать программу

Использование команды debugger аналогично добавлению точки останова из панели Sources в браузере, но основное отличие, на которое стоит обратить внимание, заключается в том, что точки останова привязаны к номерам строк. Предположим, вы поставили точку останова на строке 20, а затем переработали код и удалили строку 8. То, что было в строке 20, теперь окажется в строке 19 и вам придётся переставить на новое место точку останова. Подробности об отладке в Chrome и разные полезные сведения об этом процессе можно узнать, обратившись к документации.

Обратите внимание на то, что похожие средства отладки имеются в браузерах Firefox, Safari и Edge.

Инструменты разработчика Chrome — вкладка Network

Если вы не знаете точно, выполнен ли запрос к серверу, перейдите к вкладке Network инструментов разработчика Chrome. Посмотрите на список вызовов для запроса, в котором вы не уверены. Вы можете проверить код состояния запроса, просмотреть заголовки запроса и другие сведения о нём.

Работа в браузере: вкладка Network инструментов разработчика Chrome показывает запросы к серверу. Щелчок по строке запроса позволяет просмотреть заголовки и другие сведения

№2: React Developer Tools

Если ваше приложение основано на React и нужно проверить значения свойств или состояний, вам стоит познакомиться с расширением React Developer Tools для Chrome. Оно немедленно станет вашим лучшим другом.

Добавив в Chrome это расширение и перейдя на страницу, созданную с помощью React, вы увидите в консоли разработчика вкладку React, которая выводит значения свойств и состояния для элемента, по которому вы щёлкнете.

Работа в браузере: вкладка React показывает значения свойств и состояния если они существуют для выбранного элемента

№3: отладка серверного кода и Node Inspect

Итак, вы уверены в том, что программа работает, что данные уходят на сервер, но не знаете, правильно ли Node или Express маршрутизируют и обрабатывают запрос. Если вы используете приложение, в исходный код которого взглянуть не можете, например, это некое API стороннего сервиса, тогда почитайте документацию. Если же вы сами разрабатываете и поддерживаете сервер, тогда вам стоит познакомиться с Node Inspect.

Node Inspect похож на инструменты разработчика Chrome, но предназначен он для серверного кода. Прежде чем пользоваться этим средством, проверьте версию Node, она должна быть не ниже 6.6, и версию Chrome, которая должна быть не ниже 55. Если эти требования выполнены, откройте командную строку и выполните команду следующего вида:

node --inspect PATH_TO_YOUR_SERVER_FILE После этого вы должны увидеть сообщение, в котором нам наиболее интересна ссылка.

Отладка серверного кода: включение отладчика Node

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

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

№4: проверка ответа сервера — Postman

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

Postman — это настольное приложение, его надо скачать и установить. Оно позволяет выбрать вид запроса (среди них — GET, POST, PUT, PATCH, DELETE), добавить нужную вам конечную точку, а если надо — то и данные для аутентификации, и отправить запрос на сервер. Ответ сервера появится в приложении на вкладке Body.

Работа в Postman: выберите вид запроса, введите сведения о конечной точке, данные для аутентификации, и нажмите кнопку Send. Ответ сервера появится на вкладке Body

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

№5: синтаксические ошибки и Webpack

В борьбе с синтаксическими ошибками весьма полезен линтер, подключённый к текстовому редактору, например, ESLint. Сообщения об ошибках в консоли браузера или в командной строке также обычно помогают понять, на что стоит обратить внимание и какую строку стоит искать в тексте для исправления синтаксической ошибки. Ещё одно полезное средство проверки синтаксиса, хотя и менее известное в таком качестве — это Webpack. Да — это тот же самый Webpack, который используют для компиляции модулей.

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

Работа с Webpack: Если Webpack не может скомпилировать код, он выдаст ошибку и сведения о том, где именно, с точностью до символа в строке, она произошла.

Итоги: что делать, если ошибка не исчезает

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

Уважаемые читатели! Как вы ищете ошибки в JavaScript-коде?

habr.com


 

..:::Новинки:::..

Windows Commander 5.11 Свежая версия.

Новая версия
IrfanView 3.75 (рус)

Обновление текстового редактора TextEd, уже 1.75a

System mechanic 3.7f
Новая версия

Обновление плагинов для WC, смотрим :-)

Весь Winamp
Посетите новый сайт.

WinRaR 3.00
Релиз уже здесь

PowerDesk 4.0 free
Просто - напросто сильный upgrade проводника.

..:::Счетчики:::..