Comments 10
В качестве самоличного лога ошибок (только для себя) очень неплохо использовать Debug_HackerConsole товарища Котерова. Очень удобно: получается вроде как бы и на сайт ошибки-то выводятся, и самому сайту не мешают.
Но вот в сеть это выставлять уже не стоит, нечего пользователям знать о таком.
Но вот в сеть это выставлять уже не стоит, нечего пользователям знать о таком.
Самый оптимальный способ отлаживать веб-сайты - не отлаживать их вообще :-) Из опыта использования Ruby on Rails могу сказать, что юнит-тесты в большинстве своем исключают надобность отладки.
TDD сильно уменьшает необходимость в отладке.
Первый вариант в JSP/Servlets уже давно. На страницу выводится только 500 ошибка с указанием где упало. А более подробная информация только в логах.
Второй вариант можно дополнить включеним дебуга в конфигурационном файле.
Второй вариант можно дополнить включеним дебуга в конфигурационном файле.
всегда использовал echo print print_r
В asp.net есть просранство имен System.Diagnostics с классами для записи трассировки в логи, которые потом можно посмотреть через страницу ~/trace.axd
кроме того стандартный дебагер vs2005 позволяет выполнять пошаговую трассировку и ставить breakpoint'ы
рекомендую.
кроме того стандартный дебагер vs2005 позволяет выполнять пошаговую трассировку и ставить breakpoint'ы
рекомендую.
Да, аналогично для скриптования в PHP, в "Zend Studio" есть Debugger и брейкпоинты, так же и в простом редакторе PHP Experd Editor есть Debugger и брейкпоинты.
Но лично я, уж извините за "дет-сад", методом: мысленной диагностики вариантов данных вводимых в часть кода и выводимых из нее; и еще с "print ..." или "print_r(...)" таких данных.
Но лично я, уж извините за "дет-сад", методом: мысленной диагностики вариантов данных вводимых в часть кода и выводимых из нее; и еще с "print ..." или "print_r(...)" таких данных.
Если писать на php, то zend debug/xdebug очень помогает. Кстати на хабре были статьи о нем.
Sign up to leave a comment.
[prog] debug при разработке сайтов