Я скопировал следующий код Ruby из Интернета и внес несколько изменений.
Но это не работает!
Пожалуйста помоги. Что я могу сделать, чтобы отладить программу самостоятельно?
Установить через:
$ gem install pry
$ pry
Затем добавьте:
require 'pry'; binding.pry
в вашу программу.
По pry 0.12.2 однако, нет никаких команд навигации, таких как next, break и т.д. Некоторые другие драгоценные камни, кроме того, обеспечить это, смотри, например, pry-byedebug.
В Ruby:
ruby -rdebug myscript.rb
тогда
b <line>: поставить точку остановаn(ext) или s(tep) и c(ontinue)p(uts) для отображения(например, отладка perl)
В Rails: запустите сервер с помощью
script/server --debugger
и добавьте debugger в код.
Как рекомендуют перила: используйте pry! Я могу только согласиться на это.
pry намного лучше, чем irb.
Вам нужно добавить
require 'pry'
в исходный файл а затем вставьте контрольную точку в исходный код, добавив
binding.pry
в том месте, где вы хотите взглянуть на вещи (это похоже на запуск точки останова в классической среде IDE)
Как только ваша программа попадает в
binding.pry
вы будете брошены прямо в ремень, со всем контекстом вашей программы под рукой, так что вы можете просто исследовать все вокруг, исследовать все объекты, изменить состояние и даже изменить код на лету.
Я считаю, что вы не можете изменить код метода, который вы сейчас используете, поэтому вы можете с грустью не изменять следующую строку, которая будет выполнена. Но хороший код рубина в любом случае имеет тенденцию быть одной строкой; -)
Отладка путем создания исключений гораздо проще, чем косоглазиться с помощью операторов журналов print, а для большинства ошибок - намного быстрее, чем открытие отладчика irb, например pry или byebug. Эти инструменты не должны быть вашим первым шагом.
Exception, а затем .inspect его результатСамый быстрый способ отладки кода Ruby (особенно Rails) - это raise исключение вдоль пути выполнения вашего кода при вызове .inspect метода или объекта (например, foo):
raise foo.inspect
В приведенном выше коде raise запускает Exception, который останавливает выполнение вашего кода, и возвращает сообщение об ошибке, которое удобно содержит .inspect информацию об объекте/методе (т.е. foo) в строке, которая вы пытаетесь отлаживать.
Этот метод полезен для быстрого изучения объекта или метода (например, это nil?) и для немедленного подтверждения того, что строка кода даже вообще выполняется в рамках данного контекста.
byebug или pryТолько после того, как у вас есть информация о состоянии потока выполнения ваших кодов, вы должны рассмотреть возможность перехода к отладчику IRB от рубинового драгоценного камня, например pry или byebug, где вы можете глубже погрузиться в состояние объектов в пути выполнения.
Когда вы пытаетесь отладить проблему, всегда рекомендуется всегда: Прочитать сообщение об ошибке @@$$ (RTFM)
Это означает, что вы внимательно и полностью читаете сообщения об ошибках перед тем, как действовать, чтобы вы поняли, что он пытается сказать вам. Когда вы отлаживаете ошибку, задайте следующие психические вопросы в этом порядке при чтении сообщения об ошибке:
nil?)В трассировке стека обратите особое внимание на строки кода, которые поступают из вашего проекта (например, строки, начинающиеся с app/..., если вы используете Rails). В 99% случаев проблема связана с вашим собственным кодом.
Чтобы проиллюстрировать, почему интерпретация в этом порядке важна...
Вы выполняете код, который в какой-то момент выполняется как таковой:
@foo = Foo.new
...
@foo.bar
и вы получите сообщение об ошибке:
undefined method "bar" for Nil:nilClass
Начинающие видят эту ошибку и думают, что проблема заключается в том, что метод bar равен undefined. Это не так. В этой ошибке важна действительная часть:
for Nil:nilClass
for Nil:nilClass означает, что @foo равен Nil! @foo не является переменной экземпляра foo! У вас есть объект nil. Когда вы видите эту ошибку, она просто рубится, пытаясь сказать вам, что метод bar не существует для объектов класса nil. (ну, так как мы пытаемся использовать метод для объекта класса foo not nil).
К сожалению, из-за того, как написана эта ошибка (undefined method "bar" for Nil:nilClass), ее легко обмануть, думая, что эта ошибка связана с bar undefined. Когда вы не читаете внимательно, эта ошибка заставляет новичков ошибочно переходить к деталям метода bar на foo, полностью упуская часть ошибки, которая указывает, что объект имеет неправильный класс (в данном случае: nil), Это ошибка, которую легко избежать, читая сообщения об ошибках целиком.
Резюме:
Всегда тщательно читать все сообщение об ошибке перед началом любой отладки. Это означает: всегда проверяйте тип объекта class в сообщении об ошибке сначала, а затем методы, прежде чем вы начнете следить за любым стеклом или строкой кода, где, по вашему мнению, может произойти ошибка. Эти 5 секунд могут сэкономить вам 5 часов разочарования.
tl; dr: Не жгите в журналах печати: вместо этого создавайте исключения. Избегайте кроличьих отверстий, тщательно читая ошибки перед отладкой.
Распечатайте переменные, когда это возможно. (Это называется отладки printf). Вы можете сделать это, запустив
STDERR.puts x.inspect
или
STDERR.puts "Variable x is #{x.inspect}"
Если вы хотите сделать это проще для ввода, вы можете использовать exemplor gem.
Включите предупреждения. Если вы используете ruby, запустите его с помощью переключателя -w (например, ruby -w script.rb). Если вы используете его из irb, и используете версию ruby до 1.9.2, введите $VERBOSE = true в начале сеанса. Если вы пропустили переменную экземпляра, после того, как будут предупреждения, вы получите
предупреждение: переменная экземпляра
@valeusне инициализирована
Понимать концепцию бинарной отбивной (следующая цитата из Практики гибкого разработчика)
Разделите проблемное пространство пополам и посмотрите, какая половина содержит проблему. Затем разделите эту половину пополам и повторите.
Если вам удалась бинарная отбивная, вы можете обнаружить, что есть одна строка, которая не делает то, что вы ожидаете от нее. Например
[1, 2, 3].include?([1,2])
дает значение false, даже если вы думаете, что он вернет true. В этом случае вы можете посмотреть документацию. Веб-сайты для документации включают ruby-doc.org или APIdock. В последнем случае вы должны ввести include? рядом с увеличительным стеклом рядом с верхним правом углом, выберите include?, у которого Array под ним (если вы не знаете, какой класс [1, 2, 3], введите [1, 2, 3].class в irb), и вы попадаете в include? (Массив), в котором описывается, что он делает.
Однако, если документация не помогает, вы, скорее всего, получите хороший ответ, если можете задать вопрос о том, как определенная строка не делает то, что должна, а не почему весь script не делает то, что должно.
удаляет все вещи
Добро пожаловать в 2017 ^ _ ^
Хорошо, поэтому, если вы не против тестирования новой среды IDE, вы можете сделать следующее бесплатно.
launch.json для использования полей "cwd" и и "program" с помощью макроса {workspaceRoot}"showDebuggerOutput" и установите его на true"debug.allowBreakpointsEverywhere": truevscode; это не то же самое, что Visual Studio. Он свободный, легкий и, как правило, положительно расценивается.View->Extensions.vscode, а там будет файл с именем launch.json, где мы собираемся хранить некоторые параметры конфигурации,
launch.json Содержание
{
"version": "0.2.0",
"configurations":
[
{
"name": "Debug Local File",
"type":"Ruby",
"request": "launch",
"cwd": "${workspaceRoot}",
"program": "{workspaceRoot}/../script_name.rb",
"args": [],
"showDebuggerOutput": true
}
]
}
File->Preferences->Settings (или Ctrl ,) и прокрутите страницу до тех пор, пока вы не достигнете раздела Debug. Разверните его и найдите поле под названием "debug.allowBreakpointsEverywhere" - выберите это поле и щелкните значок маленького карандаша и установите его на true.После выполнения всего этого забавного материала вы сможете установить точки останова и отладки в меню, подобное этому в середине 2017 года, и более темную тему: < img src= "https://i.stack.imgur.com/1zCb2.jpg" alt= "введите описание изображения здесь" > со всеми интересными вещами, такими как стек вызовов, просмотр переменных и т.д.
Самый большой PITA: 1) установка предварительных требований и 2) сохранение конфигурации файла .vscode\launch.json. Только №2 должен добавить какой-либо багаж в будущие проекты, и вы можете просто скопировать достаточно общую конфигурацию, такую как указанная выше. Там, вероятно, более общее расположение конфигурации, но я не знаю, с моей точки зрения.
Все остальные ответы уже дают почти все... Просто небольшое дополнение.
Если вам нужен еще один IDE-подобный отладчик (не CLI) и не бойтесь использовать Vim в качестве редактора, я предлагаю Vim Ruby Debugger плагин для него.
Его документация довольно проста, поэтому следуйте по ссылке и смотрите. Короче говоря, это позволяет вам установить точку останова в текущей строке в редакторе, просматривать локальные переменные в отличном окне на паузе, переходить в/в - почти все обычные функции отладчика.
Для меня было довольно приятно использовать этот отладчик vim для отладки приложения Rails, хотя богатые возможности логгера Rails почти устраняют необходимость он.
Я только что обнаружил этот драгоценный камень (превращает Прай в отладчик для MRI Ruby 2. 0+)
https://github.com/deivid-rodriguez/pry-byebug
Установить с помощью:
gem install pry-byebug
затем используйте точно так же, как pry, отметьте строку, на которой вы хотите разбить:
require 'pry'; binding.pry
Однако, в отличие от vanilla pry, в этом геме есть несколько ключевых GDB-подобных команд, таких как next, step и break:
break SomeClass#run # Break at the start of 'SomeClass#run'.
break Foo#bar if baz? # Break at 'Foo#bar' only if 'baz?'.
break app/models/user.rb:15 # Break at line 15 in user.rb.
break 14 # Break at line 14 in the current file.
-w (предупреждения)Я настоятельно рекомендую это видео, чтобы в настоящий момент выбрать подходящий инструмент для отладки нашего кода.
https://www.youtube.com/watch?v=GwgF8GcynV0
Лично я выделил две большие темы в этом видео.
Что мои два цента!
Чтобы легко отладить оболочку Ruby script, просто измените ее первую строку:
#!/usr/bin/env ruby
в
#!/usr/bin/env ruby -rdebug
Затем каждый раз, когда отображается консоль отладчика, вы можете выбрать:
c для продолжения (к следующему исключению, точке останова или строке с помощью: debugger),n для следующей строки,w/where для отображения стека кадров/вызовов,l Показать текущий код,cat, чтобы показать точки catchpoint.h для получения дополнительной справки.Смотрите также: Отладка с ruby-debug, Ключевые ярлыки для рубинового отладочного камня.
Если script просто висит, и вам нужна обратная трассировка, попробуйте использовать lldb/gdb как:
echo 'call (void)rb_backtrace()' | lldb -p $(pgrep -nf ruby)
а затем проверьте процесс переднего плана.
Замените lldb на gdb, если он работает лучше. Префикс sudo для отладки не принадлежащего ему процесса.
Начиная с Ruby 2.4.0, легче запустить сеанс IRB REPL в середине любой программы Ruby. Поместите эти строки в точку программы, которую вы хотите отлаживать:
require 'irb'
binding.irb
Вы можете запустить Ruby-код и распечатать локальные переменные. Введите Ctrl + D или quit, чтобы закончить REPL, и пусть программа Ruby будет работать.
Вы также можете использовать puts и p для печати значений из вашей программы по мере ее запуска.
Если вы используете RubyMine, отладка рубиновых скриптов проста и понятна.
Предположим, что у вас есть Ruby script hello_world.rb
Установите точку останова в строке 6, как показано ниже.
Теперь вы можете просто запустить отладчик для запуска script:
Затем, когда выполнение попадает в точку останова, вы сможете проверять переменные и т.д.
отладка printf
Всегда были споры вокруг методов отладки, некоторым людям нравится отлаживать заявления печати, некоторые другие любят рыть глубоко отладчиком.
Я предлагаю вам попробовать оба подхода.
На самом деле один из старых мужчин Unix недавно сказал: что отладка printf была более быстрым способом для него в некоторых случаях.
Но если вы новичок в какой-то работе и должны понимать большой код кода, то это действительно полезно, чтобы шаг на всем протяжении, помещая некоторые точки останова здесь и там, вместе с тем, как это работает.
Он должен дать вам некоторое представление о том, как скомпилирован код.
Если вы новичок в программном обеспечении других народов, Это может помочь вам пройти через него.
Вы быстро узнаете, устроили ли они это умным способом, или если это просто куча дерьма.
Ну, Ruby standard lib имеет простой в использовании gdb-консольный отладчик: http://ruby-doc.org/stdlib-2.1.0/libdoc/debug/rdoc/DEBUGGER__.html Нет необходимости устанавливать какие-либо дополнительные драгоценные камни. Сценарии Rails тоже можно отлаживать.
например.
def say(word)
require 'debug'
puts word
end
Мать всего отладчика - это простой старый экран печати. В большинстве случаев вы, вероятно, хотите только проверить некоторые простые объекты, быстрый и простой способ:
@result = fetch_result
p "--------------------------"
p @result
Это будет распечатывать содержимое @result для STDOUT с линией спереди для удобства идентификации.
Бонус, если вы используете инфраструктуру с поддержкой автозагрузки/перезагрузки, например Rails, вам даже не нужно перезагружать приложение. (Если код, который вы отлаживаете, не перезагружается из-за специфических настроек структуры)
Я считаю, что это работает для 90% использования для меня. Вы также можете использовать ruby-debug, но я нахожу его чрезмерным.
Существует множество отладчиков с различными функциями, на основе которых вы делаете выбор. Мои приоритеты были удовлетворены любопытством, которое было: