Я хочу добавить, что отладчик не всегда является идеальным решением и не всегда должен быть подходящим решением для отладки. Вот несколько случаев, когда отладчик может не работать:
- Часть вашей программы, которая терпит неудачу, действительно велика (возможно, плохая модульность?), И вы не совсем уверены, с чего начать пошаговое выполнение кода. Прохождение всего этого может занять слишком много времени.
- Ваша программа использует множество обратных вызовов и других методов нелинейного управления потоком, что сбивает с толку отладчик, когда вы проходите через него.
- Ваша программа многопоточная. Или, что еще хуже, ваша проблема вызвана состоянием гонки.
- Код, в котором есть ошибка, запускается много раз, прежде чем выйдет из строя. Это может быть особенно проблематично в основных циклах или, что еще хуже, в физических движках, где проблема может быть числовой. Даже установка точки останова в этом случае просто заставит вас ударить ее много раз, а ошибка не появится.
- Ваша программа должна работать в режиме реального времени. Это большая проблема для программ, которые подключаются к сети. Если вы установите точку останова в своем сетевом коде, другой конец не будет ждать, пока вы перейдете, он просто истечет. Программы, которые полагаются на системные часы, например, игры с пропуском кадров, тоже не намного лучше.
- Ваша программа выполняет некоторую форму деструктивных действий, таких как запись в файлы или отправка электронной почты, и вы хотели бы ограничить количество раз, которое вам нужно запускать через нее.
- Вы можете сказать, что ваша ошибка вызвана неверными значениями, поступающими в функцию X, но вы не знаете, откуда эти значения. Необходимость запускать программу снова и снова, устанавливая точки останова все дальше и дальше назад, может быть огромной проблемой. Особенно, если функция X вызывается из многих мест по всей программе.
Во всех этих случаях либо резкая остановка вашей программы может привести к отличию конечных результатов, либо пошаговое выполнение вручную в поисках одной строки, в которой вызвана ошибка, - это слишком хлопотно. Это в равной степени может произойти независимо от того, является ли ваша ошибка неправильным поведением или сбой. Например, если повреждение памяти вызывает сбой, к тому времени, когда сбой происходит, он находится слишком далеко от того места, где впервые произошло повреждение памяти, и никакой полезной информации не остается.
Итак, каковы альтернативы?
Самый простой - это просто регистрация и утверждения. Добавьте журналы в свою программу в различных точках и сравните то, что вы получите, с тем, что вы ожидаете. Например, посмотрите, вызывается ли функция, в которой, по вашему мнению, есть ошибка. Посмотрите, соответствуют ли переменные в начале метода тем, о чем вы думаете. В отличие от точек останова, это нормально, если в журнале есть много строк, в которых ничего особенного не происходит. После этого вы можете просто просмотреть журнал. Как только вы попадете в строку журнала, которая отличается от ожидаемой, добавьте еще в той же области. Сужайте его все дальше и дальше, пока он не станет достаточно маленьким, чтобы можно было регистрировать каждую строку в области с ошибками.
Утверждения могут использоваться для перехвата неверных значений по мере их появления, а не после того, как они имеют видимый для конечного пользователя эффект. Чем быстрее вы обнаружите неправильное значение, тем ближе вы окажетесь к строке, которая его произвела.
Рефакторинг и модульное тестирование. Если ваша программа слишком велика, возможно, стоит тестировать ее по одному классу или по одной функции за раз. Дайте ему входные данные, посмотрите на выходы и посмотрите, какие из них не соответствуют вашим ожиданиям. Возможность сузить ошибку от всей программы до одной функции может иметь огромное значение во времени отладки.
В случае утечки памяти или перегрузки памяти используйте соответствующие инструменты, которые могут анализировать и обнаруживать их во время выполнения. Возможность определить, где действительно происходит повреждение, - это первый шаг. После этого вы можете использовать журналы, чтобы вернуться туда, где были введены неверные значения.
Помните, что отладка - это процесс, идущий в обратном направлении. У вас есть конечный результат - ошибка - и вы найдете причину, которая ему предшествовала. Речь идет о движении назад, и, к сожалению, отладчики только шагают вперед. Именно здесь хороший журнал и посмертный анализ могут дать вам гораздо лучшие результаты.