Я могу ошибаться, но я считаю, что суть точек останова заключается в том, чтобы приостановить состояние приложения, просмотреть его предыдущее / текущее состояние и циклически перебрать каждую «точку останова» для выявления дыр, ошибок и нарушений.
Меня никогда не учили использовать это, и я считаю, что использую гораздо более примитивный, но распространенный подход к отладке. Console.logs. Console.logs везде.
Для меня «точка останова» эквивалентна размещению console.info в том месте, где должна возникнуть «точка останова», чтобы понять состояние конкретного объекта / класса / и т. д.
Однако что-то мне подсказывает, что это далеко от идеала, и мне не хватает того, что кажется очень ценным навыком отладки. Все, кого я знаю, кто является талантливым разработчиком, профессором и менеджером, похоже, сильно полагаются на точки останова, но из-за поиска в Google я не могу найти никаких убедительных объяснений того, как их использовать в большей степени, чем простые журналы консоли.
В этом вопросе мы надеемся получить ответ о том, как отличить менталитет «регистратора консоли» от того, что кажется более продвинутой формой отладки: точки останова.
P.S. Я пометил javascript и ajax, так как это то, что я использую, и мой вопрос в первую очередь ориентирован на эти две категории, однако я уверен, что это применимо ко всем языкам и общей культуре оптимальной отладки.
Да, я «понимаю» это с чисто контекстной точки зрения, но на практике, как мне собрать все эти данные без журналов консоли? Это означает ... состояние приложения мало что говорит мне, если у меня нет полного обработчика / расширения состояния для его отображения (например, представление redux), но помимо этого, трудно различить текущее состояние и то, что я ищу? Опять же, я не говорю, что вы ошибаетесь, я предполагаю, что я не понимаю, как это использовать, что, как я считаю, ограничивает мои возможности отладки.
Отладчик покажет вам простые структуры данных. Не нужно ничего, чтобы распечатать или «изобразить» состояние. Вы можете проверить значения любых переменных в любой момент выполнения. При поиске ошибки вы просто смотрите на те, которые, как вы подозреваете, ошибочны - точно так же, как вы бы сейчас их регистрировали, но намного быстрее и проще.
а) вы можете устанавливать точки останова без изменения кода (и, возможно, перекомпиляции) б) вы можете выполнять текущее выполнение сломать и проверять произвольные части состояния программы в) вы можете выполнять отдельные инструкции вместо того, чтобы восстанавливать поток управления из ограниченного (или подавляющие) результаты вашей регистрации