我已经用Ruby/Rails编写了将近9个月的代码,在此之前我使用了Python。
虽然我真的很喜欢Rails,但有一个地方我经常感到沮丧:追捕顽固的bug。在其他语言中,我几乎总是可以在没有太多麻烦的情况下找到困难,但是当我碰到墙壁调试rails时,我往往会遇到麻烦。我想我要问的是:高级rails用户采用什么策略来追踪更顽固的错误?
目前,我的方法通常是:
如果任何先进的rails用户会分享他们的策略来追踪更顽固的bug,我会非常感激的。简而言之,当跟踪/调试器没有提供任何线索时,您会做什么?
发布于 2011-09-08 11:44:36
在Rails工作仅仅5年,我不认为自己是一个先进的铁路者,但我会很高兴地分享我的知识。:-)
在处理任何错误(除了一些非常、非常琐碎的问题)时,主要的事情是为这个bug编写一个测试。
有几次,我在这个阶段解决了这个错误--例如,当这个bug与自动类重新加载相关时,这个类在开发中是活动的,并且在测试模式下关闭。
然后,我通常只是将一些logger.debug语句与大量的inspect和caller(0).join("\n\t")放在一起。然后,我非常仔细地检查日志文件。
因为“test.log”可以有几百兆字节,所以在我运行测试之前,我总是记得对其进行零化。同时,我通常只运行一种测试方法,因为否则输出将不可读。
我不使用专用调试器。在一些老版本的ruby调试器停止工作,我学会了生活没有它,从来没有回头。
一些可能有用的实用工具:
~/.bashrc中定义的一个函数,它允许我调用单个测试方法(或一组方法):
$ testuj test/unit/user_test.rb -n test_name_validations
$ testuj test/unit/user_test.rb -n /_name_/function testuj () {
if [ -n "${BUNDLE_GEMFILE}" ]
then
# This is a Rails3 project - it is run by `bundle exec`
ruby -I"lib:test" "$@"
else
# This is a Rails1 project. No bundler.
ruby -e 'ARGV.each { |f| load f unless f =~ /^-/ ; break if f == "-n" }' "$@"
fi
}这个方法帮助我记录和检查一些步骤的时间:
Object.module_eval do
def czekpoint(note = nil)
n = Time.now
$czekpoint_previous ||= n
$czekpoint_number ||= 0
$czekpoint_number += 1
t = n - $czekpoint_previous
msg = "CZEKPOINT: %2d %8.6f %s %s" % [$czekpoint_number, t, caller.first.to_s.in_yellow, note.to_s.in_red]
Rails.logger.debug msg # In older Rails it was RAILS_DEFAULT_LOGGER
STDERR.puts msg
$czekpoint_previous = n
end
end发布于 2012-01-18 06:50:35
我个人认为,启动rails控制台并手动完成这些操作有助于解决大多数“难以跟踪”的bug。但是,最近我开始使用pry,并在我想调试的代码中添加"binding.pry“调用。似乎诀窍在于找出将binding.pry调用放在哪里。您继承的视图代码和复杂的测试代码都是非常宝贵的。
发布于 2018-05-04 10:21:44
您可以使用多种宝石进行调试,其中最流行的是pry和byebug,它们都可以帮助您在开发过程中快速、轻松地跟踪bug。
对于生产,我建议设置一个rollbar来报告生产服务器中所有未处理的错误和异常。下面是一个简单的关于在rails中调试的文章,它可以帮助您解决问题。
https://stackoverflow.com/questions/7347000
复制相似问题