几乎每个人都回答这个问题。我的版本打印任何rails异常到日志将是:

begin
    some_statement
rescue => e
    puts "Exception Occurred #{e}. Message: #{e.message}. Backtrace:  \n #{e.backtrace.join("\n")}"
    Rails.logger.error "Exception Occurred #{e}. Message: #{e.message}. Backtrace:  \n #{e.backtrace.join("\n")}"
end

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

这将产生错误描述和漂亮的、缩进的stacktrace:

begin               
 # Some exception throwing code
rescue => e
  puts "Error during processing: #{$!}"
  puts "Backtrace:\n\t#{e.backtrace.join("\n\t")}"
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”，但位置是正确的。

IRB对这个糟糕的“特性”有一个设置，你可以自定义。

创建一个名为~/的文件。Irbrc，包括以下行:

IRB.conf[:BACK_TRACE_LIMIT] = 100

这将允许你在irb中至少看到100个堆栈帧。我还没有找到非交互式运行时的等效设置。

关于IRB定制的详细信息可以在Pickaxe书中找到。