如何获得红宝石来打印完整的回溯记录而不是被截断的回溯记录？

当我得到异常时，通常是在调用堆栈的深处。发生这种情况时，我通常隐藏了真正令人讨厌的代码行：

tmp.rb:7:in `t': undefined method `bar' for nil:NilClass (NoMethodError)
        from tmp.rb:10:in `s'
        from tmp.rb:13:in `r'
        from tmp.rb:16:in `q'
        from tmp.rb:19:in `p'
        from tmp.rb:22:in `o'
        from tmp.rb:25:in `n'
        from tmp.rb:28:in `m'
        from tmp.rb:31:in `l'
         ... 8 levels...
        from tmp.rb:58:in `c'
        from tmp.rb:61:in `b'
        from tmp.rb:64:in `a'
        from tmp.rb:67

“ ... 8个级别...”的截断给我带来了很多麻烦。我对此没有太大的成功：我如何告诉ruby我希望转储包括整个堆栈？

Exception＃backtrace具有整个堆栈：

def do_division_by_zero; 5 / 0; end
begin
  do_division_by_zero
rescue => exception
  puts exception.backtrace
  raise # always reraise
end

（灵感来自Peter Cooper的Ruby Inside博客）

如果您想要一个简单的单线服务，也可以这样做：

puts caller

这将产生错误描述和简洁的缩进堆栈跟踪：

begin               
 # Some exception throwing code
rescue => e
  puts "Error during processing: #{$!}"
  puts "Backtrace:\n\t#{e.backtrace.join("\n\t")}"
end

IRB具有此可怕“功能”的设置，您可以对其进行自定义。

创建一个~/.irbrc包含以下行的文件：

IRB.conf[:BACK_TRACE_LIMIT] = 100

这样irb至少可以看到100个堆栈帧。我没有找到非交互式运行时的等效设置。

有关IRB定制的详细信息，请参见“ 镐”一书。

一种用于呼叫堆栈的衬垫：

begin; Whatever.you.want; rescue => e; puts e.message; puts; puts e.backtrace; end

一种没有所有宝石的呼叫堆栈衬套：

begin; Whatever.you.want; rescue => e; puts e.message; puts; puts e.backtrace.grep_v(/\/gems\//); end

一个呼叫堆栈的衬里，没有所有的gem和相对于当前目录

begin; Whatever.you.want; rescue => e; puts e.message; puts; puts e.backtrace.grep_v(/\/gems\//).map { |l| l.gsub(`pwd`.strip + '/', '') }; end

如果这对您很重要，它将模仿正式的Ruby跟踪。

begin
  0/0  # or some other nonsense
rescue => e
  puts e.backtrace.join("\n\t")
       .sub("\n\t", ": #{e}#{e.class ? " (#{e.class})" : ''}\n\t")
end

有趣的是，它无法正确处理“未处理的异常”，将其报告为“ RuntimeError”，但位置正确。

尝试加载测试环境时（通过rake测试或自动测试）时遇到了这些错误，IRB建议无济于事。我最终将我的整个test / test_helper.rb包裹在一个begin / rescue块中，然后进行了修复。

begin
  class ActiveSupport::TestCase
    #awesome stuff
  end
rescue => e
  puts e.backtrace
end

[检查所有线程回溯以找出问题的根源]
当您使用多个线程时，即使完全扩展的调用堆栈仍可以向您隐藏实际的有害代码行！

示例：一个线程正在迭代ruby Hash，另一线程正在尝试对其进行修改。繁荣！例外！而且，在尝试修改“忙”哈希时遇到的堆栈跟踪问题是，它向您显示了功能链，直到您试图修改哈希的地方，但并没有显示谁正在并行地对其进行迭代（谁拥有它）！这是通过打印当前所有正在运行的线程的堆栈跟踪来解决这一问题的方法。这是您的操作方式：

# This solution was found in comment by @thedarkone on https://github.com/rails/rails/issues/24627
rescue Object => boom

    thread_count = 0
    Thread.list.each do |t|
      thread_count += 1
      err_msg += "--- thread #{thread_count} of total #{Thread.list.size} #{t.object_id} backtrace begin \n"
      # Lets see if we are able to pin down the culprit
      # by collecting backtrace for all existing threads:
      err_msg += t.backtrace.join("\n")
      err_msg += "\n---thread #{thread_count} of total #{Thread.list.size} #{t.object_id} backtrace end \n"
    end

    # and just print it somewhere you like:
    $stderr.puts(err_msg)

    raise # always reraise
end

上面的代码段即使对于教育目的也很有用，因为它可以向您显示（例如X射线）实际有多少个线程（相对于您以为有多少个线程-通常这两个是不同的数字；）

您还可以使用backtrace Ruby gem（我是作者）：

require 'backtrace'
begin
  # do something dangerous
rescue StandardError => e
  puts Backtrace.new(e)
end